Optimize allocations in analyzer driver state tracking for syntax tree action analysis. Instead of tracking state for all pending trees, we now track state only for trees which have started analysis. This ensures we don't create state tracking entries for all trees in compilation at start of analysis - these entries show up in perf traces.
I have also changed the declaring references cached on SymbolDeclaredEvent to be lazily computed. If we end up computing only syntax diagnostics on a compilation, this will save us allocations.

Ensure that we use a single CompilationWithAnalyzers instance for computing diagnostics with the LatestDiagnosticsGetter (FixAll code path and other explicit GetDiagnostics requests to the diagnostic service). This avoids us cloning the compilation and re-running analyzer compilation start actions once per each document for which we need to compute diagnostics.

Background analysis based off the solution crawler still creates a new CompilationWithAnalyzers instance per document analysis request as caching it in memory causes high VM usage.

This change addresses the FixAll performance regression in VS2015 Update1 reported in https://github.com/DotNetAnalyzers/StyleCopAnalyzers/pull/1979#issuecomment-166656002.

1. Add support for a simulated event queue to generate compilation events by computing declarations in the tree. Invoking GetDiagnostics to populate the event queue is one of the main reason for large allocations/VM in our perf tests. We can get back to using the compilation event queue when the compiler supports attaching an event queue to an existing compilation, without requiring a complete clone.

2. Move the cached compilation data (declarations, suppression state, etc.) out of a conditional weak table and strongly reference it in CompilationWithAnalyzers.

3. Reduce allocations in per-analyzer state maintenance by tracking analyzed declarations instead of pending declarations - latter can be very large for symbols with many declarations (e.g. global namespace).

1. Ensure that CompilationWithAnalyzers processes symbol declared events for analyzers with just Operation actions (Fixes #7308)

2. Fix the InvalidOperationException from operation action reporting a diagnostic in live analysis (Fixes #7324)

3. Add telemetry for Operation action counts registered per-analyzer. This involves a public API change, basically extending the existing telemetry API for other action counts.

This reverts commit 268e7d38, reversing
changes made to 98790c02.

Conflicts:
    src/Compilers/Core/Portable/DiagnosticAnalyzer/AnalyzerDriver.cs

This change replaces synchronous lock statements in the core analyzer executor and analyzer state tracker (for IDE live analysis) with semaphore slim DisposableWaitAsync invocations. This ensures that most of the analyzer driver and analyzer executor code is now async, with only the eventual callback into the analyzers being a synchronous method ([ExecuteAndCatchIfThrows_NoLock](http://source.roslyn.io/Microsoft.CodeAnalysis/R/02d7df8203d3591e.html))

Testing: I verified that the self-build time of Roslyn.sln (which uses a few analyzers), is almost identical after this change. We are hoping that this will improve build performance when there is lot of lock contention, which has shown up from perf traces (see https://github.com/dotnet/roslyn/issues/6053).

Fixes #6399

This change replaces synchronous lock statements in the core analyzer executor and analyzer state tracker (for IDE live analysis) with semaphore slim DisposableWaitAsync invocations. This ensures that most of the analyzer driver and analyzer executor code is now async, with only the eventual callback into the analyzers being a synchronous method ([ExecuteAndCatchIfThrows_NoLock](http://source.roslyn.io/Microsoft.CodeAnalysis/R/02d7df8203d3591e.html))

Testing: I verified that the self-build time of Roslyn.sln (which uses a few analyzers), is almost identical after this change. We are hoping that this will improve build performance when there is lot of lock contention, which has shown up from perf traces (see https://github.com/dotnet/roslyn/issues/6053).

Fixes #6399

- CompilationWithAnalyzerOptions should be sealed
- CompilationWithAnalyzerOptions.AnalyzerOptions should be renamed Options
- SuppressionInfo should be sealed
- AnalyzerTelemetry API changes as per [this](https://github.com/dotnet/roslyn/issues/5974#issuecomment-149987997) comment.

There are no functionality changes here.

Fixes #6044

1) Reduce number allocations in the analyzer driver that show up perf traces for Picasso.
2) Currently we maintain a cache of CompilationWithAnalyzers for projects being actively analyzed. This is causing the VM to rise and also forcing GC to kick in at different phases causing regressions at various scenarios. The fix is to just create a new CompilationCompilationWithAnalyzers instance for each document/project analysis request.

1) Perf traces show large GC activity during diagnostic analysis. Switched a ConditionalWeakTable added in the v2 driver change from being keyed on SyntaxReference to being keyed on Compilation, with the value being a dictionary keyed on SyntaxReference's Location. Also added cache cleanup logic to ensure entries from this dictionary get cleared as declarations are analyzed across all analyzers.
2) With the v2 driver refactoring, we stopped using the descriptor cache for analyzers in the IDE. This change re-introduces the cache and also adds logic to avoid realizing all the compiler diagnostic descriptors during diagnostic analysis.

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.