Since they can be used in subsequent submissions, they are always
considered to be used.

Fixes #4392

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.

As an optimization, submissions not containing declarations are not
emitted.  However, when we short-circuit emission, we also skip diagnostic
reporting (e.g. in usings) that can trigger an assert in the next
submission (which assumes that all errors have been reported).

Fixes #3795

This reverts commit 15443a23.

Conflicts:
	src/Compilers/CSharp/Portable/CommandLine/CommandLineParser.cs
	src/Compilers/CSharp/Portable/PublicAPI.txt
	src/Compilers/Core/Portable/PublicAPI.txt
	src/Compilers/VisualBasic/Portable/CommandLine/CommandLineParser.vb

Fixes #2888
Fixes #3786

Fell out of our normal cadence for this during the push for RTM. Now that we
had a bit more breathing room getting us back on track here.

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

This change is meant to address crashes like the ones in bug 1140649. The
crashes seem to happen due to exceptions thrown while getting a temporary
output stream to write the PE file to. I have been unable to reproduce
the conditions for the crash themselves -- they only seem to happen on
a Japanese language Windows with a Japanese language copy of Visual Studio.
This fix addresses their symptom by wrapping the CreateInputStream call
during signing with a try/catch and then surfacing the exception as a
diagnostic for signing failure.

We cannot currently add any more localized resources to stabilization, so
this fix is meant to be as targeted as possible and can only deliver
information through existing resource strings.

(cherry picked from commit 801a10a5)

This change is meant to address crashes like the ones in bug 1140649. The
crashes seem to happen due to exceptions thrown while getting a temporary
output stream to write the PE file to. I have been unable to reproduce
the conditions for the crash themselves -- they only seem to happen on
a Japanese language Windows with a Japanese language copy of Visual Studio.
This fix addresses their symptom by wrapping the CreateInputStream call
during signing with a try/catch and then surfacing the exception as a
diagnostic for signing failure.

We cannot currently add any more localized resources to stabilization, so
this fix is meant to be as targeted as possible and can only deliver
information through existing resource strings.

Changes ObjectPool leak detection to use simple light-up to get the stack trace (which is nonportable), and fixes a few leaks

Pass PDB path to PeWriter so that creating debug directory is possible w/o availability of native PDB writer

The ISymUnmanagedWriter2 interface does not require a file name be
passed.  It can successful emit a PDB without it.  The only method which
actually requires it is GetDebugInfo.

The Compilation type will call this member frequently during PDB
creation.  Hence if we have a Stream only we need to manufacture a name
to use for it.

This change further delays the creation of the PE Stream until the
absolute last possible moment.

This unifies the Stream passing API to prefer EmitStreamProvider over
Stream in the Emit APIs.  Even though we are not currently taking
advantage of the delay creation mechanism for the command line compiler
there was a desire to have consistent parameter values where possible.
The advantage is it lets us switch to making XML documentation delay
created as well with a very small change in the future.

This causes the compiler to match the native one in terms of PDB
behavior.  It will only pass along the Stream value to Initialize in the
cases where a Stream is explicitly provided.  In the other cases,
basically the raw command line, it will pass along only the file name.
This puts the responsibility of creating / writing the file solely in
ISymUnmanagedWriter as it previously was via WritePdbToOutput

This change takes the following steps:

- Changes EmitStreamProvider to wrap a single Stream instead of a group
of Stream.
- Changes the emit behavior to consider Analyzer errors before
attempting to write the PE / PDB Stream to disk.

When a compilation fails the compiler should not delete or edit the outputs of a previous successful.  They should remain around to satisfy scenarios like F5 on build failure.

Roslyn implemented this logic by doing the following:

- Creating a `Stream` for the assembly / PDB in a temp directory.
- Running the compilation.
- Moving the `Stream` to the desired output location on success.

This introduced a subtle bug into the compiler.  When the source + dest of `File.Move` are on the same volume the destination file will end up with the ACLs it got from being created in the source directory.  In this example it meant the assembly / PDB had the ACLs of the temp directory not the actual output one.

This can produce breaks in cases where the temp and output directory have different inheritable ACLS.  This case comes up for instance in ASP.Net.

To fix this we are going back to the native compiler behavior here.  The creation of the `Stream` objects will be delayed until we are ready to write to disk (happens after the compilation is verified to have no errors).

Because this portion of the compiler is on .NET 4.5.2 the Emit layer cannot open the files directly (no file system API to use).  Instead we pass down the `EmitStreamProvider` abstraction from the desktop layer and let that control the openning of the files.

This change also allows us to remove all of the temp directory logic from the compiler and build protocol.

Note: Whether or not to make this entry point a public API is being considered separately from this thread.  If we decide to make this public it will be done as a separate follow up change.

Use empty array for unspecified public key instead of default(ImmutableArray<byte>) to avoid issues with JSON serialization