Implement support for Code Lenses

[DanielRosenwasser]

This PR implements support for textDocument/codeLens and codeLens/resolve on the server side, alongside a custom client command called typescript.codeLens.showLocations.

CodeLens objects are produced by textDocument/codeLens as indicators that an editor client can get more information "later on". When codeLens/resolve is called for a given CodeLens object, the Title, Command, and command Arguments are populated appropriately so that a user can see some high-level information and potentially click on the UI decoration to trigger a command.

We produce two types of CodeLens objects: "references" code lens, and "implementations" code lens. These act as markers/indicators so that when an editor like VS Code scrolls into the view of a code lens, it will call on the server to populate each lens with a title and list of locations to preview upon clicking. This amounts to a find-all-references or go-to-implementation call when scrolling into the view of a given code lens.

The VS Code extension wires this up with a minimal client-side command which just converts the LSP objects into VS Code ones before redirecting the values to the editor's "peek" pane.

Much of the logic is roughly ported over from VS Code's Code Lens implementations, though it is not one-to-one. On an implementation level, instead of two separate providers/walks like the client did, this implementation does one walk and may produce up to two CodeLens objects, encoding how the CodeLens should be resolved later. More importantly, we have full syntactic and semantic information, so can make better judgments on what kinds of syntax should be decorated with a CodeLens if we ever want to modify the behavior.

That said, we have some differences - some that I think are desirable, and some that are just bugs.

One thing I implemented here was support for includeDeclaration in textDocument/references (aside: I find this behavior iffy for callers who "forget" to pass in includeDeclaration). I used this as a shortcut to avoid filtering out declarations in find-all-references; however, as you can see above, this gets a different "References" count because it drops overrides/implementations. I actually think that this might not be the right move, and that maybe we should only discount references containing the source position.

Current TODOs:

• Add testing capabilities and some basic tests
• Sweep up TODOs
• Fix up overloads
• Decide on how references filtering works for declarations
• Fix up how Data is handled given Jake's PR at Refine LSP with our own types, generate more stuff #2141
• Do some sort of client/server handshake to decide on the client-side command name for codeLens/resolve.

Fixes #1897

[jakebailey]

Thankfully this is opt-in, otherwise I'd be even more worried about merging this given this also uses the checker.

[jakebailey]

This is likely to conflict with Sheetal's PR, but probably in a good way given the codelens needs to do cross-project too.

[DanielRosenwasser]

I'm noticing that that PR (#1991) doesn't touch go-to-implementations, which in theory is also multi-project. I think that that should be a follow-up to this so the two have a common way to walk references across related projects.

[sheetalkamat]

I can do that part as a separate PR but strada didn’t do it so I didn’t port it in my earlier pr