Add multi-document highlight provider feature

[Yoyokrazy]

Fixes #184259
re #196240
Fixes #198469
re #196354

This pull request adds support for multi-document highlight providers, allowing for the highlighting of occurrences of a variable.

It includes:

• proposed API for multi-doc highlight providers, and registering
• generic editor feature for textual highlight provider
  • remove textual highlight from mainThreadLangFeat
• improvement to typescript-language-features extension to hook up multi-doc semantic highlighting
• hooked up exthost types and everything for multi-doc highlights
• introduced MultiDocumentHighlight

class MultiDocumentHighlight {

    /**
     * The URI of the document containing the highlights.
     */
    uri: Uri;

    /**
     * The highlights for the document.
     */
    highlights: DocumentHighlight[];

    /**
     * Creates a new instance of MultiDocumentHighlight.
     * @param uri The URI of the document containing the highlights.
     * @param highlights The highlights for the document.
     */
    constructor(uri: Uri, highlights: DocumentHighlight[]);
}

[Yoyokrazy]

Todo:

• Textual provider being called when typescript files are highlighted. Should not be using that.
  • need to score the textual provider lower/0 when there is a higher scored model?
• Potentially remove TextualOccurenceRequest from WordHighlighter.ts. Should always have the generic TextualHighlightProvider to fall back on.

[jrieken]

Left some comments and suggestions tho this is already looking very good. Nice work!

[Yoyokrazy]

All nits + feedback has been addressed. Update on the todo with the textual pieces:

• Having issues with the textual highlight provider registered editor getting called when the typescript highlight provider returns a valid (albeit empty) result. The current check leverages first and returns when a provider gives a result that evaluates true with result instanceof ResourceMap && result.size > 0. Current (not-functional) code:

// in order of score ask the occurrences provider
// until someone response with a good result
// (good = none empty array)
return first<ResourceMap<DocumentHighlight[]> | null | undefined>(orderedByScore.map(provider => () => {
	const filteredModels = otherModels.filter(otherModel => {
		return score(provider.selector, otherModel.uri, otherModel.getLanguageId(), true, undefined, undefined) > 0;
	});

	return Promise.resolve(provider.provideMultiDocumentHighlights(model, position, filteredModels, token))
		.then(undefined, onUnexpectedExternalError);
}), (t: ResourceMap<DocumentHighlight[]> | null | undefined): t is ResourceMap<DocumentHighlight[]> => t instanceof ResourceMap && t.size > 0);

• My thought was to shift to a "good" result being = non-null and non-undefined. In other words, a Resource map could be returned containing any number of given URIs and simply not have any DocumentHighlights, and that would evaluate to true and pop out of first(). That changed the final line of the above snippet to:

(t: ResourceMap<DocumentHighlight[]> | null | undefined): t is ResourceMap<DocumentHighlight[]> => t instanceof ResourceMap && t !== null && t !== undefined);

• That continued to not pop out of first() so my further thought is that likely the typescript highligh provider was returning an empty MultiDocHighlight array upon no results. I then tweaked the implementation within documentHighlight.ts in typescript-lang-feat and set it to return undefined upon a body length of 0 (body of the response is just an empty array when clicking import). This still doesn't pop out of first(), leaving me a bit stumped on where to take this.

Currently the TextualHighlightProvider is defined, but not registered. This results in only falling back to a TextualOccurrenceRequest within WordHighlighter.ts when there is no provider in the registry for the model. This means that currently it works as intended, however just isn't an optimal situation.

Would love some feedback on this issue @jrieken, thanks! This PR is at a state that it can be merged without risk of breaking core features, it just doesn't add the generic Textual editor feature that we initially set out to implement alongside this multi-doc feature. That will get shifted to a debt item that gets addressed in the coming December work cycle.

oof and feedback/nits addressed