Add "type" to textDocument/references results

[sean-mcmanus]

VS Code issue (UI) is at microsoft/vscode#74237

The C/C++ extension wants to be able to send back references of different types that users can determine what "type" of reference it is and filter out unwanted types -- in order to provide functionality equivalent to Visual Studio 2019. The types we want are below. Feel free to change the naming of the example types.

1. Confirmed reference (i.e. passes semantic checking): e.g. Type.ConfirmedReference
2. Not a reference (i.e. has the same name, but fails semantic checking -- these non-references might be desired in some cases), e.g. e.g. Type.NotAReference
3. Reference in a comment, e.g. e.g. Type.CommentReference
4. Reference in a string, e.g. Type.StringReference
5. Reference in an inactive (preprocessor) region, e.g. Type.InactiveReference (Note: Comment/String references take precedence, so this only applies to identifiers).
6. Confirmation in progress, e.g. Type.PendingReference
7. Cannot confirm reference (due to some bug or "by design" limitation), e.g. Type.UnknownReference

It's possible other reference types might be desirable as well for other languages or scenarios.

This is the screenshot from VS:

Our current "workaround" is to either send back multiple "types" merged together (ambiguously) or allow users to filter out types via a setting or a progress UI button, e.g. "show confirmed references", "show unconfirmed references" (i.e. 6 and 7).

The relevant LSP that would need to be changed is at
https://microsoft.github.io/language-server-protocol/specification#textDocument_references

[sean-mcmanus]

We also want a similar "type" to be returnable with textDocument/rename to allow users to filter out the rename results by type (I could file a separate issue if you want), but we don't plan to add Rename till July:

[DanTup]

I have a similar use case where there are some things that are not direct references but would be useful to include in results. For example, when using a Builder pattern:

export interface User {
	name: string; // Do find references on `name` here
}

const builder = new UserBuilder();
builder.name = "Danny"; // This is not a direct reference
const user = builder.build();

If the user does Find References on User.name they're likely looking for places that read or set that field. But since writes to it are done via a builder, none of them would show up (only the implementation in the builder that produces the User).

(See microsoft/vscode#144699).