Allow language specific handlers to use their own types for serialization

[dibarbet]

This moves the deserialization and serialization support out of StreamJsonRpc, and directly into roslyn. Before we deserialize, we figure out what language a particular handler is for (based on the text document in the parameters). If none is found we use the default language handler.

This is done by manually looking at the JToken for the uri in the expected location (LSP requests are generally uniform in where they put the URI).

This will allow XAML to use different instances of LSP serialization types as compared to Roslyn.

[mgoertz-msft]

Seems to be no longer used anywhere

[dibarbet]

Originally I was planning on pushing the deserialization down deeper into the queue (instead of before we enqueue it). However, I encountered a couple issues

1. In order to create the request context, the request needs to be deserialized. Unfortunately this has to happen serially so we cannot parallelize the deserialization like I was hoping.
2. While possible to put it in the queue, it dramatically increases the complexity of this change (many of the clasp types need to be reworked as they're expecting the real types by the time a request gets enqueued).

Additionally, I am hopeful that in the future we may be able to provide a protocol types library that can handle all of the non-breaking JSON protocol changes without binary breaking changes (generally these occur because of union type additions). This is a requirement for Razor cohosting as well. If we're able to convert XAML to using those types as well, we would no longer need to support different type definitions for the same LSP method.

[ToddGrun]

[dibarbet]

Update - the PR val cloudbuild failed due to a warning triggering in the source file includes. Running a new one now, should have results soon.