Expose Roslyn protocol types as binary dependency to Xaml, Razor

[dibarbet]

Currently, Roslyn does not (and cannot) use the VS LSP protocol type definitions due to licensing concerns in VSCode. This has caused problems for Xaml and Razor as we move them to run inside the Roslyn LSP server (both in VS and VSCode) - they use the VS LSP types which are incompatible with our custom implementation.

For XAML, we implemented support to allow them to add handlers using their types - #72230, however its caused at least one followup issue - dotnet/vscode-csharp#7024 (comment) and is relatively complex.

For Razor cohosting, they will need to call our APIs directly to get c# LSP information - however they cannot as they use VS types, and our types are not public.

To reduce complexity here and allow Razor to call us directly to get LSP information, the proposal is to change the Roslyn LSP type definitions from internal to public. In order to do this however, we need to ensure that non-breaking changes to the LSP protocol do not cause binary breaks in our type definitions (a drawback of the current VS LSP library which uses SumTypes for unions).

This issue tracks

1. Modify the Roslyn LSP types to be more resilient to non-breaking LSP protocol changes
   a. Needs some investigation. Main issue is the union types in the LSP protocol. It is not a protocol breaking change to add a union type to a field, request, or response type - but generally it is a binary breaking change unless we have special handling for it.
   b. Changes in union types in request and responses can be handled relatively easily with a wrapper type that has fields for each option in the union type. Every request/response would be defined as a wrapper type. Adding a new union type would not breaking consumers that compiled against the older version of the library (assuming the client never sends them the new type, controlled by capabilities).
   c. Changes in union types in fields is harder - each field needs to be able to at any point become a union type or add more types to the union
2. Make them available to Razor and XAML in a single binary so we ensure that we're always using binary compatible LSP types.