> Before knowing what's the best approach, I think we should clearly
> decide what would be the "ideal" new API.  E.g. should it return "any
> string" and then it'd be up to the infrastructure code to store
> side-info about what is the corresponding candidate's actual text?

After trying different variants, it turned out that the most convenient
is to use annotation-function that can contain a placeholder for the
completion candidate.  Currently "%s" is used as a placeholder,
for example, "prefix %s suffix" but it can be any string.
Or maybe better to allow returning a list of two separate strings
for prefix and suffix from annotation-function?

Here is an example used for testing: