Don't implicitly load assemblies via MEF in Roslyn language server

[DustinCampbell]

Now that Razor is moving to a "co-hosting" model in which it contributes method handlers and services into the main Roslyn language server, it turns out that Microsoft.VisualStudio.LanguageServices.Razor.dll gets loaded for C#/VB projects. None of the Razor services are actually instantiated, but the language server's MEF registration causes the assembly containing the Razor services to load. This is because the MEF metadata view for each LSP service includes the service's System.Type, which requires the service's assembly to be loaded. The language server uses that type for reflection, probing implemented interfaces and collecting information about request handler methods.

This pull request makes significant changes to CLaSP and the Roslyn language server's service registration. Instead of capturing the System.Type, the necessary reflection is performed up front in the export attributes and the reflected information is loaded into the MEF metadata view. UIn addition, a helper TypeRef class has been added to CLaSP to replace anywhere in the API that the Type is exposed. TypeRef avoids loading the actual System.Type until it's requested.

In addition, I've made several other improvements to CLaSP and LSP services:

• Removed ILspServices.SupportsGetRegisteredServices() and ILspServices.GetRegisteredServices(). This functionality is now available in CLaSP as IMethodHandlerProvider, which any ILspServices can optionally implement. (Fixes Remove Lazy Handler requirement from Roslyn LSP #63555)
• Replaced ImmutableDictionaries with FrozenDictionaries in LspServices, since the dictionaries are computed once for the lifetime of the language server.
• Fixed an issue I noticed where lazily computed base services would return new instances each time they were requested. It turned out that this didn't happen in practice (except for TelemetryService), but I decided to fix this now rather than get bitten by it later.
• Made ILspServices.TryGetService(...) follow the .NET TryGet* pattern.

PR Validation Build: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9648175&view=results
VS Insertion Build: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/554387

cc @dibarbet and @davidwengier

[davidwengier]

I think I understood this, and I think its good. I reviewed commit at a time though, so might have missed something, but GitHub is not making it easy to do anything else 😛

[dibarbet]

Overall, I am happy with the approach. I'm requesting changes for two things

1. The potential issue with typeref and assembly load context (see below)
2. A test insertion to make sure we don't have unexpected regressions- I triggered one here https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9604942&view=results

[dibarbet]

I'm probably just being dumb here - when is the RequestTypeRef not a TypeRef?

[DustinCampbell]

When it's null. This is just a null check. Previously, TypeRef was a struct and RequestTypeRef is defined as TypeRef?. So, when it was a struct, is TypeRef would pull out the value. When I changed TypeRef to a class, I decided to leave TypeRef here rather than switching over to metadata.RequestTypeRef is { } requestTypeRef, since the type name is pretty short.