bug#48841: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

["João Távora" <joaotavora@gmail.com>]

> In comparison to my last patch, the patch is fully backward
> compatible and preserves all existing tests.

This a very good thing (the fact that the patch is fully backward compatible,
I mean).

It is quite a large patch that touches many completion internals.  I'd like
some time to look it over.

I've read the discussion and am indeed aware of some non-neglibile
performance problems in the flex and pcm completion styles since
they need to copy strings around.  Other -- completely different --
performance problems affect fido-mode specifically (but not
fido-vertical-mode, curiously).

In some conversation with Dmitry

  bug#48841: fido-mode is slower than ido-mode with similar settings

We discussed this.

There was also talk of removing the string copying with minimal (but not null)
backward compatibility breakage.  I recall Dmitry saying it was easy
to fix on the
completion frontend side.  Many such frontends live in Emacs or GNU Elpa.
On the other hand, the patch that we (or at least I) envisioned in
that discussion
was almost certainly much, much simpler than the one being presented here,
and thus much easier to reason about and discuss.

But to avoid comparing apples to oranges, I would you to summarize exactly,
perhaps in the forms of code snippets, and/or benchmarks exactly what problems
your large patch solves. State the problem(s) first, then the solution
(to each).
If there are multiple problems, then there's a good chance that multiple patches
that address each of these are preferred.

Thank you very much.
João