Fix failures to use VBCSCompiler.exe for Roslyn builds

Fix improper construction of DiagnosticAnalyzerService

Add a new command line switch to skip analyzer execution

See #46684

Finish 'Generate Equals' conversion to new test library

Add restricted IVTs for IntelliCode

Fix couple of issues related to SerializableOptionSet which were leading to checkum validation asserts

* Expose generator internals:
- Add a new api + result objects to return generator driver internals
- Rework the way we handle exceptions, especially for syntax walk based operations
- Ensure we don't mix up generator and driver exceptions

Null annotate SymbolKey and a bit more of the compiler

Add integration test to configure diagnostic severity via editorconfig

Stop specifying Rich Nav's version of dotnet

Delete our use of Microsoft.VisualStudio.CodingConventions

Fixes #40926

This support was added to `Microsoft.CodeAnalysis.targets` (ships with VS) in VS2019 16.5:
https://docs.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019.

However, the MSBuild property is not respected from 'dotnet' builds where this targets file is not imported (see https://github.com/dotnet/roslyn/issues/40926#issuecomment-574506716 for details).

This change moves the skip analyzers logic down to `Microsoft.Managed.Core.targets` and core compiler layer so it is respected for all builds. As per offline discussions with Jared and Chris, we can no longer skip analyzer execution from MSBuild by removing the "Analyzer" items as these can include source generators, which should never be skipped (at least there are no current scenarios where we want to skip generators). Hence, we are adding a new command line compiler switch `/skipAnalyzers`, optionally followed by a `+` or `-`, to allow skipping analyzers.

I verified the end-to-end functionality works fine by locally building `Microsoft.Net.Compilers.Toolset.Package` NuGet package and referencing it in a project.

Combine local and LSP code action logic

Move C# editorconfig diagnostic support API to CompilationOptions, instead of SyntaxTree

I suspect this was added because we were potentially passing in
arrays with null entries, but we're checking for that now.

The various reading methods when resolving keys can potentially return
null. The rule was as follows:

1. If the thing being written can never be null, I put a ! after the
   Read call.
2. If the thing being written could be null, no suppression was
   allowed.

Essentially this means that the reading code is not expected to be
robust in the face of nulls coming from incorrectly annotated code.

Some of the types (like SymbolKeyReader) are pooled. I elected to
leave the members annotated as they act when being used normally, and
suppressed null assignments when the object was in the pool.

I would do the same for IsInMetadata, but there's a terrifying comment
on MetadataModule that says it can be null even if IsInMetadata
returns true.

It allows null, but was annotated otherwise.

Fix crash in the preview of a code action that modified an .editorconfig

Add temporary support for colorization in LSP hover

Closes https://github.com/dotnet/roslyn/issues/27715
Closes https://github.com/dotnet/roslyn/issues/42448

We had left this as a legacy mode for users who were running into
issues. We recently reset the option for anybody using 16.7 builds
after fixing some underlying issues, and we haven't heard any new
issues.

For reasons that aren't entirely clear, when we create a preview of
a code fix, we remove and re-add documents that are being changed when
we produce the PreviewWorkspace. This process had an bug which meant
that the file path of an .editorconfig got dropped, so the resultant
.editorconfig document path was null. This later caused a crash if
the diagnostic engine, when processing the PreviewWorkspace's
new solution, tried asking for a Compilation, since the null path would
get passed to AnalyzerConfig.Parse(), and it would throw.

This was exposed by #45076; until then if you had a preview of just
an .editorconfig file, nothing would actually be analyzed and so
nothing asked for the Compilation. The crash is "fixed" by #44331 in
that asking for a Compilation no longer results in a call to
AnalyzerConfig.Parse(); you have to ask for a Compilation and then do
something with a semantic model. By luck, that doesn't happen in the
common repro, but more obscure things absolutely could still fail.

This is being tested by the integration test being added in #46639. We
don't really have a good unit tests here as far as I can tell, but even
then a unit test really doesn't validate any of the end-to-end here.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1162464

Fix issue where compiler host dropped connections under load