Add new analyzer API (DiagnosticSuppressor) to allow programmatic suppression of analyzer and/or compiler non-error diagnostics

Fixes #20242 and #30172

Detailed design proposal [here](https://gist.github.com/mavasani/fcac17a9581b5c54cef8a689eeec954a).

Added public APIs with documentation comments:
```cs
namespace Microsoft.CodeAnalysis.Diagnostics
{
    /// <summary>
    /// The base type for diagnostic suppressors that can programmatically suppress analyzer and/or compiler non-error diagnostics.
    /// </summary>
    public abstract class DiagnosticSuppressor : DiagnosticAnalyzer
    {
        // Disallow suppressors from reporting diagnostics or registering analysis actions.
        public sealed override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics => ImmutableArray<DiagnosticDescriptor>.Empty;

        public sealed override void Initialize(AnalysisContext context) { }

        /// <summary>
        /// Returns a set of descriptors for the suppressions that this suppressor is capable of producing.
        /// </summary>
        public abstract ImmutableArray<SuppressionDescriptor> SupportedSuppressions { get; }

        /// <summary>
        /// Suppress analyzer and/or compiler non-error diagnostics reported for the compilation.
        /// This may be a subset of the full set of reported diagnostics, as an optimization for
        /// supporting incremental and partial analysis scenarios.
        /// A diagnostic is considered suppressible by a DiagnosticSuppressor if *all* of the following conditions are met:
        ///     1. Diagnostic is not already suppressed in source via pragma/suppress message attribute.
        ///     2. Diagnostic's <see cref="Diagnostic.DefaultSeverity"/> is not <see cref="DiagnosticSeverity.Error"/>.
        ///     3. Diagnostic is not tagged with <see cref="WellKnownDiagnosticTags.NotConfigurable"/> custom tag.
        /// </summary>
        public abstract void ReportSuppressions(SuppressionAnalysisContext context);
    }

    /// <summary>
    /// Provides a description about a programmatic suppression of a <see cref="Diagnostic"/> by a <see cref="DiagnosticSuppressor"/>.
    /// </summary>
    public sealed class SuppressionDescriptor : IEquatable<SuppressionDescriptor>
    {
        /// <summary>
        /// An unique identifier for the suppression.
        /// </summary>
        public string Id { get; }

        /// <summary>
        /// Identifier of the suppressed diagnostic, i.e. <see cref="Diagnostic.Id"/>.
        /// </summary>
        public string SuppressedDiagnosticId { get; }

        /// <summary>
        /// A localizable description about the suppression.
        /// </summary>
        public LocalizableString Description { get; }
    }

    /// <summary>
    /// Context for suppressing analyzer and/or compiler non-error diagnostics reported for the compilation.
    /// </summary>
    public struct SuppressionAnalysisContext
    {
        /// <summary>
        /// Suppressible analyzer and/or compiler non-error diagnostics reported for the compilation.
        /// This may be a subset of the full set of reported diagnostics, as an optimization for
        /// supporting incremental and partial analysis scenarios.
        /// A diagnostic is considered suppressible by a DiagnosticSuppressor if *all* of the following conditions are met:
        ///     1. Diagnostic is not already suppressed in source via pragma/suppress message attribute.
        ///     2. Diagnostic's <see cref="Diagnostic.DefaultSeverity"/> is not <see cref="DiagnosticSeverity.Error"/>.
        ///     3. Diagnostic is not tagged with <see cref="WellKnownDiagnosticTags.NotConfigurable"/> custom tag.
        /// </summary>
        public ImmutableArray<Diagnostic> ReportedDiagnostics { get; }

        /// <summary>
        /// Report a <see cref="Suppression"/> for a reported diagnostic.
        /// </summary>
        public void ReportSuppression(Suppression suppression);

        /// <summary>
        /// Gets a <see cref="SemanticModel"/> for the given <see cref="SyntaxTree"/>, which is shared across all analyzers.
        /// </summary>
        public SemanticModel GetSemanticModel(SyntaxTree syntaxTree);

        /// <summary>
        /// <see cref="CodeAnalysis.Compilation"/> for the context.
        /// </summary>
        public Compilation Compilation { get; }

        /// <summary>
        /// Options specified for the analysis.
        /// </summary>
        public AnalyzerOptions Options { get; }

        /// <summary>
        /// Token to check for requested cancellation of the analysis.
        /// </summary>
        public CancellationToken CancellationToken { get; }
    }

    /// <summary>
    /// Programmatic suppression of a <see cref="Diagnostic"/> by a <see cref="DiagnosticSuppressor"/>.
    /// </summary>
    public struct Suppression
    {
        /// <summary>
        /// Creates a suppression of a <see cref="Diagnostic"/> with the given <see cref="SuppressionDescriptor"/>.
        /// </summary>
        /// <param name="descriptor">
        /// Descriptor for the suppression, which must be from <see cref="DiagnosticSuppressor.SupportedSuppressions"/>
        /// for the <see cref="DiagnosticSuppressor"/> creating this suppression.
        /// </param>
        /// <param name="suppressedDiagnostic">
        /// <see cref="Diagnostic"/> to be suppressed, which must be from <see cref="SuppressionAnalysisContext.ReportedDiagnostics"/>
        /// for the suppression context in which this suppression is being created.</param>
        public static Suppression Create(SuppressionDescriptor descriptor, Diagnostic suppressedDiagnostic);

        /// <summary>
        /// Descriptor for this suppression.
        /// </summary>
        public SuppressionDescriptor Descriptor { get; }

        /// <summary>
        /// Diagnostic suppressed by this suppression.
        /// </summary>
        public Diagnostic SuppressedDiagnostic { get; }
    }
}
```

For batch compilation, suppressors always run after all the analyzer diagnostics have been computed.
For IDE partial/incremental analysis scenario, we may run the suppressors with partial diagnostics.
Suppressed diagnostics from diagnostic suppressors are equivalent to source suppressed diagnostics: they show up in the error list with "Suppression State" column as "Suppressed" and are also output to errorlog as suppressed diagnostics.

1. Check cancellation at multiple places.
2. Run partial tree completion logic sequentially when `AnalysisOptions.ConcurrentAnalysis = false`

This new proposed diagnostic analyzer API enables analyzing all executable code (syntax nodes/operations/code blocks) with a symbol and it's member.

1. `AnalysisContext.RegisterSymbolStartAction(Action<SymbolStartAnalysisContext>, SymbolKind)` and `CompilationStartAnalysisContext.RegisterSymbolStartAction(Action<SymbolStartAnalysisContext>, SymbolKind)` to register actions to be invoked for every symbol of a given kind, prior to invoking any other actions within the symbol and it's members.
2. `SymbolStartAnalysisContext.RegisterXXXEndAction` APIs to register symbol-specific syntax node/operation/code block actions.
3. `SymbolStartAnalysisContext.RegisterSymbolEndAction` to register an action to be invoked at the end of all analysis of symbol, its members and all executable code within it.

This change ports the MakeFieldReadonlyAnalyzer to use the new API, which adds support for partial types to this analyzer.
Fixes #25652

Remove the AnalyzerManager singleton to prevent storing analyzer execution state across compilations

Now we throw away all the analyzer execution state once the CompilationWithAnalyzers goes out of scope.

My motivation for doing this is to pick up the new PublicAPI checker
that understands type forwards. In doing so I disabled a bunch of new
warnings that are either broken or not really applicable to Roslyn.
One new warning (don't rethrow exceptions with throw ex;) seemed useful
enough to keep on so I left it on and fixed the one offense in the
codebase.

Ensure that we don't execute Initialize and compilation start actions for analyzers with no enabled rules

Fixes #15184

In Update2, we switched over to simulated event queue generation to work around the performance issues from computing closed file diagnostics. New IDE diagnostics engine added in Update3 doesn't compute syntax/semantic diagnostics for each closed file separately, so this performance issue shouldn't show up anymore. This change moves us back to populating the event queue using GetDiagnostics.

* Fix reporting of EnC diagnostics

* Keep original overloads on DocumentDiagnosticAnalyzer for compat with TS and F#

Most of this work was done prior to Update2 to address large allocations in presence of large number of analyzers. With IDE diagnostic engine V2, we don't need this pool as we don't analyze each closed file separately, but instead run analyzers on the entire compilation.

Address performance regression in CompilationWithAnalyzers.GetAnalyzerDiagnosticsAsync and new public APIs 'GetAnalysisResultAsync' to fetch the entire analysis result with diagnostics categorized by kind (syntax, semantic, compilation), tree and analyzer.

Now only the partial analysis APIs (GetAnalyzerSyntaxDiagnosticsAsync, GetAnalyzerSemanticDiagnosticsAsync and GetAnalyzerCompilationDiagnosticsAsync) do analyzer state tracking. Rest of the APIs execute analyzers without state tracking, improving overall performance.

Fixes https://github.com/dotnet/roslyn/issues/10530

Address performance regression in CompilationWithAnalyzers.GetAnalyzerDiagnosticsAsync and new public APIs 'GetAnalysisResultAsync' to fetch the entire analysis result with diagnostics categorized by kind (syntax, semantic, compilation), tree and analyzer.

Now only the partial analysis APIs (GetAnalyzerSyntaxDiagnosticsAsync, GetAnalyzerSemanticDiagnosticsAsync and GetAnalyzerCompilationDiagnosticsAsync) do analyzer state tracking. Rest of the APIs execute analyzers without state tracking, improving overall performance.

Fixes https://github.com/dotnet/roslyn/issues/10530

Fixes VSO Bug [199252](https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems?_a=edit&id=199252)

Root cause: We were attempting to access the cancellation token for a cancellation token source within a lambda within the using statement for the token source. If client fires a cancellation before the task within the lambda executes, the token source may have been disposed when the task is eventually activated.

Fix: This change saves the cancellation token for the token source upfront for use within the lambda and also checks for cancellation before computing diagnostics.

Justification for ask mode: We are hitting this intermittent crash in perf runs in an internal VSO branch and fix doesn't have any risks.

Fixes VSO Bug [199252](https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems?_a=edit&id=199252)

Root cause: We were attempting to access the cancellation token for a cancellation token source within a lambda within the using statement for the token source. If client fires a cancellation before the task within the lambda executes, the token source may have been disposed when the task is eventually activated.

Fix: This change saves the cancellation token for the token source upfront for use within the lambda and also checks for cancellation before computing diagnostics.

Justification for ask mode: We are hitting this intermittent crash in perf runs in an internal VSO branch and fix doesn't have any risks.

Fixes #8178

Fixes VSO Watson #187814

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).

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

Add a new CompilationOption "ReportSuppressedDiagnostics" to enable reporting compiler diagnostics suppressed in source. Note that the command line compilers will report such suppressed diagnostics in the SARIF errorlog file but not on the console output.

This new compilation option was approved by the design team.

Fixes #5216

Primary issue is that we currently try to force complete and decode SuppressMessageAttributes in the analyzer callbacks to report a diagnostic. We need to decode these attributes to apply source suppressions to reported diagnostics. However, force completing attributes can lead to us binding more symbols, and subsequently generating more symbol declared events and attempting to callback into the analyzer again.

Fix is to decode the suppress message attributes as a post pass in the analyzer driver and avoid any symbol force completion during analyzer callbacks to report diagnostics.

Fixes #4858

Emit "isSuppressedInSource" boolean property for diagnostics in the ErrorLog file and report suppressed analyzer diagnostics in the error log.

1. CompilationWithAnalyzers can now report analyzer diagnostics with source suppressions (pragma/SuppressMessageAttribute). This will eventually allow us to surface diagnostics with source suppressions in the error list. Note that the behavior of command line compilers and all the GetDiagnostics APIs is unchanged, only the compiler analyzer will report diagnostics with source suppressions.

2. Add FixAll support for Suppression code fixes. Light bulb suppression fixes now show the "Fix all occurrences" options for Document/Project/Solution. This change adds the basic functionality to bulk suppress diagnostics. This will eventually be consumed for baselining all/selected diagnostics from error list/solution explorer.

3. Simplify the Suppression light bulb menu to remove the option to add a local SuppressMessageAttribute. The only options now are to suppress in source (pragma) or suppressions file (assembly level SuppressMessageAttribute).

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.

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

Expose a public API for consumers of CompilationWithAnalyzers to clear off analyzer state cached during analyzer execution.

Executing analyzers requires us to internally store state such as supported diagnostics, registered actions, exception handlers for analyzer exceptions, etc. for the entire lifetime of analyzers. However, the lifetime of the analyzer instances is controlled only by the analyzer host, i.e. the consumer of CompilationWithAnalyzers. We cannot implicitly clear this internal state when disposing CompilationWithAnalyzers as the analyzer host might be re-using the same analyzer instances across multiple CompilationWithAnalyzers instances.

Fix is to expose an API on CompilationWithAnalyzers to allow the analyzer host to explicitly clear stored analyzer state, when it is done using analyzer instances.

Long term solution is to make the AnalyzerManager public and remove its static instance, so that the analyzer host can explicitly control its lifetime.

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.