Merge stabilization into master

Merge remote-tracking branch 'upstream/stabilization' into merge-stabilization-into-master20160430-150024

Accessibility Improvements

Use a pool that doesn't leak memory in highly concurrent scenarios.

Remove 'RoslynCompilerExtensionActive' variable

Fix the "Unused parameter" sample analyzers to ignore compiler genera…

Install Vsix as part of Automation

Remove all the static analyzer state tracking pools in CompilationWit…

Fix the MakeConstCS and MakeConstVB samples to specify the analyzer a…

Fix the "Unused parameter" sample analyzers to ignore compiler generated parameters with no locations.

Note that the corresponding FxCop analyzer (CA1801) is based on IOperation and hence doesn't hit this situation (https://github.com/dotnet/roslyn-analyzers/blob/master/src/Microsoft.Maintainability.Analyzers/Core/ReviewUnusedParameters.cs#L128)

Fixes #10314

I verified that make const diagnostics now show up when these projects are set as startup projects and deployed to dev hive.

Fixes #3215

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.

Disable 'Populate Switch' in master.  We'll be shipping this out of Future instead.

Refactor reference assembly searching vs package searching.

Update corefx refs to -rc2-24027

Fix race in ProcessRunner.cs where we might not wait for output

turn on v2 diagnostic engine as default

* Create vsix that contains all roslyn dependencies

It's possible to get Process.OutputDataReceived or ErrorDataReceived
to fire after you've got the Exited message from the process. You must
call WaitForExit to confirm that everything is completely done before
continuing. Otherwise, we return still-mutating lists to the caller
who started the Process which isn't going to be ready for that.

Consume VS SDK tasks and targets via NuGet

Show FixAll progress when the user invokes a long-runnning light bulb.

The NuGet packages for the SDK don't currently support cross-targeting,
so we must pick the right version to consume based on the version of
Visual Studio you are targeting. I implement this by simply restoring
both versions, and conditioning our MSBuild includes to the right one.
The annoying bit is since we need to restore two different versions
of the same package name via NuGet, we have to put the dependencies
in separate project.json files.

Fixes #10407.

Add using should not make innapropriate spell checking fixes.

Fixes #10911