Auto replace

[Aerijo]

This changes the replacementPrefix logic to remember the original range from the server, and attempt to match it as close as possible.

I won't be merging this soon, because I need some time for myself and others to see how terrible this attempt is and how it can be refined. It also needs tests added for the new behaviour. Also need to handle insertText gracefully.

Design

When we request a new set of completions, we note

• the trigger point (TP) and
• the original buffer position we requested at (OBP).

Each suggestion from the server can have a custom range (single line is enforced by spec), but we expect most to match [TP, OBP]. The ones that don't have a custom prefix added from the custom start (CS) to OBP. As we also invalidate the cache if BP < OBP, this ensures CS <= OBP <= BP and so that part of the prefix is static.

E.g., it might look like

v CS                  v CE
 " . / p a t h / f i "
            TP^  OBP^

The spec is unclear about how to treat the ranges when the cursor moves. I feel like the following is a natural choice:

• The start remains absolutely stationary. Changes earlier in the file that would move it will invalidate the cache anyway.
• The end remains logically stationary relative to BP. So if we type out lename from OBP, then the CE will still be two columns to the right of BP, on the right side of the ". This handling cannot be done properly as-is, because there is no relationship between the cursor position (BP) and the text that has been typed. A proper solution would add a marker to all the distinct suggestion end points, and let the editor keep them logically stationary. But right now the distinction is pointless because we can't remove the text after the cursor anyway.

@isundaylee I'm not going to try and fix the end part of the replacement in this PR like we discussed. It's already complicated enough as it is. The fix would only apply to Text suggestions too, as snippets may be using snippet syntax in that range.

[Aerijo]

OK, I've updated the autocomplete tests. The old ones focused heavily on the details of the internal methods, which meant any changes would easily break them. The new tests only check the results of converting various different CompletionItem's into Autocomplete+ Suggestions, without specifying how the actual conversion should work.

I'll merge when they pass, and then try it out with the various current servers before making a release and bumping their versions.