* make diagnostic analyzer service lazy and not require UI thread.

require ExtensionManager change that got checked into 15.8

* change location where we log number of workspace analyzer references due to it being lazy now.

* PR feedback

We take the analyzer references provided from VSIX extensions and create
a map of AnalyzerReference.Id -> AnalyzerReference, which is done by
cracking the metadata and getting the .NET assembly identity for them.
We were doing this on the UI during package load, which really isn't
necessary.

* removed dead code

* added a way to order Document/ProjectDiagnosticAnalyzer.

this is to let partner team such as typescript and F# to be able to order their analyzers

* use => instead of {get;} =

* PR feedbacks

first one is preview workspace leak due to diagnostic service hold onto workspace.
second is capturing project in diagnostic exception handler

Customer scenario: User installs any VSIX based analyzer into their extensions hive, but the analyzers and fixers from the installed extension don't work.

Reason: While making the features layer portable, we changed the analyzer assembly loader for VSIX based analyzers to use the PEReader to get the assembly name for loading the assembly. Prior to that, we used to invoke the desktop API "AssemblyName.GetAssemblyName", which sets the CodeBase property of the returned assembly name to be full path of the assembly. Assembly.Load would attempt to load the ngen'ed image of the assembly, and if it doesn't exist then search will eventually fall back to loading the managed assembly at the CodeBase location. We lost the latter functionality when we made the above change, which causes the assembly loader to fail loading the assembly at the specified full path.

Fix: Move the analyzer assembly loader to the non-portable VS diagnostic analyzer provider service. Any host which needs to support VSIX based analyzers must also implement the assembly loader for VSIX analyzers.

Testing: Verified that assemblies from VSIX based analyzer extensions get loaded successfully and the diagnostics/code fixes work fine. Also added a unit test to verify that host analyzer manager can load assemblies from custom install paths - verified that test fails prior to this change.

Fixes #6285

Changes include:

1. Enhance CompilationWithAnalyzers to allow computing analyzer diagnostics for a specific tree/span within a compilation and/or for a subset of analyzers. Implementation ensures no duplicate analysis by tracking partial analysis state and caching the reported analyzer diagnostics.

2. Overview of the new APIs added to CompilationWithAnalyzers:
    1. GetAnalyzerSyntaxDiagnostics(tree, analyzers, ct)
        1. Analogous to SyntaxTree.GetDiagnostics(ct)
        2. Gets analyzer diagnostics reported by executing syntax tree actions on the given tree.
    2. GetAnalyzerSemanticDiagnostics(semanticModel, spanOpt, analyzers, ct)
        1. Analogous to SemanticModel.GetDiagnostics(spanOpt, ct)
        2. Gets analyzer diagnostics reported by executing rest of the non-compilation actions on the given tree span.
    3. GetAnalyzerCompilationDiagnostics(analyzers, ct)
        1. Gets rest of the analyzer diagnostics which are reported by either of the following means:
            1. Compilation actions (and compilation end actions)
            2. Non-compilation actions reporting diagnostics on different tree: Executing a symbol action on a symbol definition in a tree, can report diagnostic on its partial definition in some other tree.

3. Simplify IDE analyzer driver by switching it to using the new CompilationWithAnalyzers APIs for analyzer diagnostic computation. Both the IDE and compiler drivers now use the compilation event queue model for driving analysis.

Update `AnalyzerFileReference` to take an `IAnalyzerAssemblyLoader`
instead of a `Func<string, Assembly>`.

Fixes #1710.

We can easily run into the situation where the same analyzer assembly is
appears twice: once as an `<AnalyzerReference>` in the project, and once
in a VSIX installed in VS. We don't want to run the analyzer twice, so
currently the `HostAnalyzerManager` in VS checks
`AnalyzerReference.DisplayName` and excludes any analyzers from VSIXes
that match analyzers from the project.

This works for the moment, but it isn't what `DisplayName` was designed
for. Instead, this commit adds an `Id` property to `AnalyzerReference`
and updates the `HostAnalyzerManager` to make use of it.

now, error list will have column (which is off by default) that shows source of each errors in a
format "assembly name" for analyzers node. and "assembly name" [vsix name] for vsix

previously we made system to prefer live diagnostic over build diagnostic.
also when we merge those two, we used very detail info to find out build and live diagnostics are same or not.

but the issue was diagnostics from build didn't have all information live one has, also diagnostics from build is static
when live one is changing as user type in IDE. which lead to race where build diagnostic might be already out-dated on arrival.

new system is that we prefer diagnostic from build over live. and don't distinguish them by detail info but whether live can produce
same diagnostics build produced. as user change file, we will replace build diagnostics in affected files to live diagnostics.

this should remove chance where build diagnostic got stuck in the system until next build. and as user change files, live diagnostic
over take build diagnostics.

all tests passing. now StateManager owns all state related operation.

and added place holder for state manager

It ensures the following for the lifetime of analyzer host:
1) DiagnosticAnalyzer.Initialize(AnalysisContext) is invoked only once per-analyzer.
2) DiagnosticAnalyzer.SupportedDiagnostics is invoked only once per-analyzer.
3) CompilationStartAnalyzerActions registered during Initialize are invoked only once per-analyzer per-compilation.

rename some of method to more clearly indicate what can be cached in manager and what must be cached by caller.

GetXXX method is used for information that manager can cache or already cached. CreateXXX method is used for information that manager can't cache.

fixed reporting issue and de-duplication issues.