Replacing ILanguageServerProtocol with AbstractRequestHandlerProvider.
Refactoring common Extensions method code into generic helpers.

Added XAML LSP shims by introducing ILanguageServerProtocol and adding an optional Language parameter to the ExportLspMethodHandlerAttribute so that XAML can export its own LSP handlers.
Added a few extension methods to make dealing with TextDocuments easier.

- The language server platform is properly implementing solution close understanding for local language servers and I found that when testing their bits Roslyn would explode gloriously. Turns out shutdown and exit support just wasn't fully enabled yet.
- When the language server platform reboots language servers it re-invokes Activate and because of that Roslyn explodes because the language client has already been activated and there was previously a contract throws check on already being initialized.
- Implemented the `ShutdownAsync` target on the `InProcLanguageServer` to detach from the diagnostic service.
- Implemented the `ExitAsync` target on the `InProcLanguageServer` to properly dispose our `JsonRpc` object.

This replaces our existing "GetDocumentFromURI" helper with one that
instead takes the full TextDocumentIdentifier, and uses the context
information to figure out which document to use in the case of
multi-targeting or linked documents.

Update diagnostics publishing to include uris from previously published diagnostics as well as current diagnostics.

ASP.NET Razor is prototyping a system where they can add files into
our workspace via IDynamicFileInfoProvider and can then query our LSP
server to get diagnostics about those files. They're normally closed
files but we want them to get analyzed always if they want to query
them via LSP, and we also don't want those diagnostics to end up in the
error list since further processing needs to be done with them with
LSP.

This implements a hook where Razor can specify that diagnostics produced
for their documents are ingored by most of the system, but can still
be queried through their special LSP server.

Razor needs us to return the mapped span so that the diagnostics are properly located in the actual razor file,
rather than the underlying c# buffer.  In non razor scenarios, it appears that the mapped span = original span,
so it should be safe to always return the mapped span.  The diagnostic data location's SourceSpan doesn't appear
to ever be mapped so we ignore it.