This change increases the severity of analyzer exception diagnostic (AD0001), generated when an analyzer throws an exception, from info to a warning. Additionally, its descriptor is now reported as a supported diagnostic descriptor of the compiler analyzer, which ensures that it shows up in the ruleset editor.

Fixes #3707

We execute the analyzer driver's initialization and core analysis tasks on a background thread. Any exceptions from the driver itself (not the analyzer callbacks, we already report diagnostics for those) were getting swallowed and analyzer execution also skipped silently. See #2980 (comment) for an example.

We now report an exception diagnostic for analyzer driver crash (with the complete exception trace), so that the user knows what happened and we can diagnose the bug when the issue is reported.

Fixes #3005

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.

Add DiagnosticDescriptor.GetEffectiveSeverity(CompilationOptions) API to get the effective severity of diagnostics created based on the descriptor for the given compilation options.

This change also removes the clone of this functionality in the IDE layer used by the solution explorer rule severity display and error list/diagnostic service. It now uses this public API.

Fixes #2598

we have changed AnalyzerFileReference.Id to include versions, public keys and etc as its identity.

some internal data structure that generates string from it didn't changed accordingly.

this should fix the issue.

Add a new command line compiler switch "/reportanalyzer" to report analyzer execution times. Output is grouped by analyzer assemblies and is displayed in descending order of execution times.

NOTE: We do not display the total build time or the ratios between build time and analyzer execution time as the the actual wall clock time for analyzer execution is likely lesser due to multithreaded analyzer execution.

Added a null check in the AnalyzerHelper for Languages that don't
participate in the compilation. Since TypeScript doesn't participate in
the Compilation we get a null reference exception on the compilation
options.

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

1) Statically created LocalizableString instances by analyzers were holding onto instances of AnalyzerExecutor (which holds onto the compilation on which it executes) for exception reporting, causing us to leak compilations in command line builds. Fixed this by making sure that we unregister these exception handlers during analyzer cleanup in CommonCompiler, we already did so for VisualStudioAnalyzer created in IDE.

2) Switch all the state caches in AnalyzerManager to be keyed with analyzer, and clear all state for analyzer when host disposes it. Performance analysis showed that analyzers that capture the CompilationStartAnalysisContext in its RegisterCompilationStartAction via some lambda were rooting the compilation objects.

Above two changes got rid of all the static and dependent handles rooting compilations during command line builds, and I see a perceived reduction in memory used by VBCSCompiler during building Roslyn.

3) Fix the IDE onAnalyzerException delegate to not capture project instance, but instead use the projectId. Otherwise, VSIX analyzers that live for lifetime of VS instance would leak compilations.

While I was at it, I also got rid of functionality added to MetadataCache that was caching and re-using analyzer instances across AnalyzerFileReference instances, we had already decided to instead keep lifetime of analyzer instances bound by lifetime of owning AnalyzerFileReference.

Fixes #252 : If an analyzer reports a diagnostic with an unsupported diagnostic ID, i.e. no descriptor returned by SupportedDiagnostics has that ID, then throw an ArgumentException in ReportDiagnostic method. This exception would be turned into an analyzer diagnostic by the driver and reported back to the analyzer host.
Also fix a few tests that were reporting diagnostics with unsupported ID!

Address feedback from Tom: Ensure that we unsubscribe the exception handler registered with LocalizableString when the analyzer reference is disposed by the host. This will prevent statically instantiated LocalizableString instances from leaking the handler, and hence the analyzer instance.
We now have a public OnException event on the LocalizableString, which is invoked on exceptions. AnalyzerManager registers host's exception handler when populating descriptor cache per analyzer and unregisters this handler when host is disposing the analyzer.

some code clean up - rename and such

Been almost a month since the code formatter was run so this change was
a bit larger than would be expected for a normal (weekly) update.  Diffs
mostly around:

- Whitespace changes
- Missing copyright headers
- Missing visibility modifiers

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