User scenario: Analysis might get skipped in the IDE for a symbol/partial declarations for a partial symbol with more than one definition in a single document.

Cause: When computing symbols declared in the tree to generate symbol declared events, we were adding duplicate entries if a symbol had more than one partial declaration in a tree. This meant that multiple threads might start performing symbol analysis on the same symbol, causing a race condition as driver doesn't expect duplicate events. Though we ensure not to make duplicate callbacks, we might end up missing on making some callbacks at times.

Fix: Compute only unique symbols from declarations in a tree.

Risk: None, it is a trivial fix.

Testing: Before the fix, I was able to repro the race condition and the assert consistently by running the flaky test in a loop for over 10k times. After the fix, it doesn't repro on running the same multiple times. A new unit test has also been added, though it did not fail consistently even before the fix.

Fixes #9462

Fixes #3748

A regression test has been added for this bug.

Fixes #3748

A regression test has been added for this bug.

Fixes #3748

A regression test has been added for this bug.

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.

Ensure that analyzer driver processes declared namespace symbols which are scoped to source assembly being analyzed, not the merged namespace symbols with declaring references across the compilation (including referenced assemblies).

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. Add a new API: AnalysisContext.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags analysisMode)
Configures analyzer callbacks + diagnostic reporting for the analyzer. Recommended for analyzer authors to always invoke this API.

2. Analyzer driver uses a heuristic to identify generated code:
  1. Symbols marked with GeneratedCodeAttribute.
  2. Files with specific extensions (see [here](http://source.roslyn.io/Microsoft.CodeAnalysis.Workspaces/R/ef3599fb042e3706.html)).
  3. Files which have a single line comment starting with <auto-generated> at the beginning of a source file.

3. Driver defaults for non-configured analyzers:
  1. Run analysis on generated code: This avoids semantic breaks for analyzers and will be guaranteed to be always enabled in future.
  2. Report all diagnostics on generated code: This will likely be changed to perform some level of default filtering after #3705 is implemented.

Fixes #6998

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

Remove caching of declaring syntax references for symbols in analyzer driver - this was done as part of addressing some performance regressions, but the subsequent tuning should make the original change redundant.

Fixes #7156

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.