Log non-fatal-watson if exception is not caused by stack overflow in OperationWalker.

1) Remove the field Default - analyzer authors can avoid calling the ConfigureCodeAnalysis API if they want driver's default behavior.

2) Change the value of ReportDiagnostics to 2

Fixes #9048

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.

Completed API review changes except for guaranteeing that no operation kind indicates IStatement or IExpression.

Address performance issues in the AnalyzerManager reported at https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/2078#issuecomment-181150995:

1. Replace use of ConcurrentDictionaries with Dictionary + lock.
2. Avoid unncessary ToImmutableArray invocations.

I also fixed up a subtle race condition in CompilationAnalysisValueProvider.TryGetValue for my last PR (see https://github.com/dotnet/roslyn/pull/8375/files#r52127390).

Fixes VSO Watson #187814

Fixes #3748

A regression test has been added for this bug.

Fixes #3748

A regression test has been added for this bug.

Enable per-file state caching in analyzer. The state can be shared across analyzer actions and also across different analyzer instances.

Fixes #6324

Add OwningSymbol and Compilation properties to OperationAnalysisContext and SyntaxNodeAnalysisContext.

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

Code cracker recently added an analyzer that accidentally reports diagnostics with a location in a syntax tree outside of the current compilation. We were not handling this case gracefully and causing VS to crash. Code cracker fixed their analyzer and released an updated package. This change guards against such cases by ignoring such diagnostics and reporting an analyzer exception diagnostic about invalid diagnostic.

Fixes #7173

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

By default, analyzer driver never makes concurrent callbacks into a single analyzer instance. This change adds a new public API 'AnalysisContext.RegisterConcurrentExecution' to enable thread-safe analyzers to receive concurrent callbacks, which should theoretically improve performance of such analyzers for concurrent builds.

Fixes #6737