The implementation in SolutionState.RemoveDocumentsFromMultipleProjects
is heavily inspired (i.e. copy/pasted and tweaked appropriately) from
AddDocumentsToMultipleProjects.

* Make finding checksum async
* Clean up TryRunCodeAnalysisRemoteAsync

Respect RunAnalyzers and RunCodeAnalysisDuringLiveAnalysis project properties for VSIX analyzer execution

We recently added project properties for configuring analyzer execution during build and live analysis, see documentation [here](https://docs.microsoft.com/visualstudio/code-quality/disable-code-analysis). Currently, these properties are only respected for NuGet based analyzers. This PR adds support to respect these properties even for VSIX based analyzers, including the built-in IDE code style analyzers. https://github.com/dotnet/project-system/pull/5598 passes the required properties down to the Roslyn langauge service, and this PR consumes these properties and adds this support.

1. Renamed "Set Rule Set Severity" command to "Set severity". Also renamed "Info" and "Hidden" sub-menus to "Suggestion" and "Silent" respectively to align with our editorconfig severity terminology.
2. The set severity command handler checks if the project uses no ruleset or the default built-in ruleset, and if so it adds or updates editorconfig to configure severity. Otherwise, we continue using specified ruleset for configuration.
3. Updated the effective ruleset severity computation for the rule nodes under Analyzers node to account for severity settings from editorconfig (analyzer config documents).

Add "AdditionalDocument" type as a sub-type of TextDocument. Also introduce a "TextDocumentKind" enum to represent different kinds of text documents and refactor existing code switching on documents to now look at document kinds.

It's not as important as the others because the file ordering doesn't
matter in the same way, but it's good to have for consistency.

We only allowed adding one-at-at-time. This aligns us with
regular documents and AnalyzerConfig documents.

This is all mechanical code that's reusing existing patterns.

This adds to ProjectState an AsyncLazy to compute the AnalyzerConfigs
that need to be applied to the documents in the project. Since the
information needs to be applied to a SyntaxTree itself, the ValueSource
is given to DocumentStates so that way any syntax tree fetch includes
this information.

This change is a fairly mechanical change and is just flowing through
the new APIs that create new documents; all the "interesting" stuff
of the actual implementation will follow.

Right now we were duplicating the logic in DocumentState.Create() that
lived inside of TextDocumentState.Create(). The usual constructor order
expresses this more naturally.

We already have an API for adding multiple project references; let's
just use that at the public entrypoints than trying to maintain
near-duplicate code.

We already have an API for adding multiple project references; let's
just use that at the public entrypoints than trying to maintain
near-duplicate code.

This is equivalent to calling Solution.AddDocument a bunch of times, but
lets us avoid some O(n) cost. For example, adding a bunch of documents
is typically always done to the same project, and so we can avoid
re-creating multiple ProjectStates, only one new CompilationTracker,
one linked file map, etc.

These can be very confusing, since other methods on Contract actually
throw exceptions. Since we have endless amounts of code directly calling
Debug.Assert, let's just use it everywhere.

This change adds an OutputRefFilePath path to the workspace API for the compiler's /refout feature.

Since ImmutableDictionary and ImmutableSortedDictionary are both
implemented via trees; you can think of an ImmutableDictionary as just
being a sorted dictionary where the underlying key is the hash int.
Since our hash is just a hash of a GUID, we can compare by the GUID,
switch to a ImmutableSortedDictionary, and then avoid another sort
when we're computing checksums.

We previously were using ImmutableArrays, so if you had a large number
of documents (say thousands) we'd be creating huge numbers of huge
arrays over and over again. For this pattern, ImmutableList is more
appropriate.