The code is separated out and can compile now.  Had to break server functionality to enable this though.

We have seen two big analyzer packages (CodeCracker and RefactoringEssentials) end up with registering async actions, which can crash VS from the async continuations.
See [this](https://github.com/code-cracker/code-cracker/issues/375#issue-87474837) for more details. Now we prevent this by disallowing analyzers to register async callbacks.

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

Revert "Revert "Revert "Revert "*DON'T MERGE INTO MASTER* Hide IOperation API behind a feature flag""""

This reverts commit d4d502e4.

This reverts commit a96d7825.

This reverts commit 92ff3f8d.

This reverts commit b03e8478.

https://github.com/dotnet/roslyn/commit/b03e84783806dc48f240e56188e6473323dc3ba1

The flag name is "IOperation". Register opeartion actions and calling
SemanticModel.GetOperation while the feature is disabled will throw an
InvalidOperationException. Also log a non-fatal-watson when
SemanticModel.GetOperation crashes.

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

Fixes #6324

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

Report a diagnostic if an analyzer reports a diagnostic with an invalid ID (has non-alphanumeric characters).

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.

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!

moved v1 engine to its own namespace and updated sources accordingly.

also added BaseDiagnosticIncrementalAnalyzer which contains all methods that engine needs to implement to make all other services which consume IDiagnosticAnalyzerService to just work.

probably later we will change it but for now, this should let us test v2 engine isolated without too much changes in other part of code base

These were accidentally changed to UTF-16LE during a recent scripted change.  This went unnoticed because the encoding change didn't register in CodeFlow (indeed if you view a shelve of this change in CodeFlow it will report no changes).  UTF-16 does not work well with Git as it is often interpreted as a binary file.  Moving back to UTF-8 so our GitHub experience works well for customers.

closes #66 (changeset 1403787)

Background:

As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

The coding style transition is automated using a Roslyn based rewrite tool:

https://github.com/dotnet/codeformatter

This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1403394)

The renamed files from my previous somehow didn't have the edits but just had the rename checked in. Checking in the edits as well. (changeset 1390443)

The IDE uses four public APIs from the compiler layer for doing running analyzers in the IDE:

1. A bunch of static methods on AnalyzerDriver called Execute*Actions which take a type called AnalyzerActions which should be an implementation detail. So first change is to create a shared project called AnalyzerDriver that is referenced by CodeAnalysis and Features layers. I've split out these statics into a type called AnalyzerDriverHelper and made that internal. One challenge in doing this is that these methods create instances of Contexts and currently their constructors are internal. I've added constructors where possible and for some contexts that were taking Scopes, I've changed them to be abstract base classes and eliminated the scopes altogether. As part of pulling these methods, I needed some collections like ArrayBuilder, PooledDictionary etc and created another shared project called SharedCollections and put them there.

2. SemanticModel.GetDeclarationsInSpan - this is used by the IDE to calculate the declarations on which to run analyzers. This has also been pulled into the shared project and the API on semantic model made internal. We need a mechanism for branching into C#\VB implementations on both sides. Hence, the compiler API on semanticmodel still exists and is internal. On the features side, I have a language service, that branches into C#\VB and the implementation simply calls into the shared code.

3,4. AnalyzerDriver.GetEffectiveDiagnsotics and AnalyzerDriver.IsAnalyzerSuppressed() are two APIs about filtering that the IDE uses. There are legitimate scenarios for both of them being public APIs even if we make the IDE simply ask the compiler to run its analyzers. For eg: the IDE will need to run Document analyzers and the compiler can never run them. It needs to filter the results after that. Filtering requires pragma state and suppressmessage etc which are compiler'y things. The plan here is to move these APIs to a type called CompilationWithAnalyzers that John is creating to replace the AnalyzerDriver.GetAnalyzerdiagnostics() method. Once that happens, we can make AnalyzerDriver fully internal. This change doesn't touch those methods.

The shared code needed to access some resources. So I've created a type called AnalyzerDriverResources in both the Codeanalysis and features projects and they redirect to the appropriate resources.
 (changeset 1390439)

Fix for bug 1087195: Add overloads to RegisterSymbolAction and RegisterSyntaxNodeAction that take ImmutableArray for symbol/syntax kinds (changeset 1378545)