Better support non-prefix (also called flex) completions

This is the start of a discussion before submitting a pull request for a protocol extension.

Some editors support what is called substring, non-prefix or sometimes "flex" completion. It means that the substring being completed is not necessarily the prefix of each completion in the result but is somehow related to it. Normally, this relation is expressed in terms of the positions of the characters of the substring in the completion string. Here's a visual example where a using is typing qload to get to multiple completions that contain the characters of that substring in different positions.

For this to work in LSP, where the substring that the user wants to complete is not at all a part of the request (it could be, but that's a whole different discussion), the server has to provide the regions of each completion that it considers are the parts of that that are already set down. So if the user requests completion somewhere around the word afoo in the document and the server decides to provides completions farfromsober and galaxyfooraway, it could/should also provide the reasoning behind this choice, so that the user can be made visually aware of it. In this case the numbers (1 3 5 8) for the first completion and (1 6 7 8) for the second completion would probably suffice: they are the 0-based indexes of the characters of afoo in the completion. Or maybe it can say (1 3 5 8) for the first and (1 (6 8)) for the second, to save some bandwidth. Note that all of this is indeed consistent with the user wanting to complete afoo, but it's up to the server to decide which a in galaxyfooraway it means.

It's also desirable that the server criteriously order the completions in the results, perhaps sorting to the top the completions where the match is more closely grouped. Fortunately LSP already already has support for that (though nothing like a "score" indication).

Well, long story short, we need a new field for the Completion data type. I propose a matchIndexes field. Maybe to JSONize the examlples it's easier [1 3 5 8] for the first example and [1 {:start 6 :end 8}] for the second example.

This isn't coming out of thin air, BTW

Start with the LSP Completion data type described in the issue and review the linked Eglot discussion for prior context. Resolve the representation and semantics of the proposed matchIndexes field, including how completion matches are ordered and displayed; done means the protocol extension is specified consistently.