TLDR: artifacts are going to move around in Binaries\Debug and the directory is going to get a lot bigger.

At a high level build projects can be classified into three categories based on how they write output:

- incorrect: a given output path is written to more than once with different contents
- less correct: a given output path is written to more than once but always with the same content
- correct: a given output path is written to exactly once

Today the roslyn build is decidedly “incorrect” as pretty much every file is written directly into Binaries\Debug. This means it ends up writing pretty much every Visual Studio SDK DLL twice: once for Dev14 and once for Dev15. For example at various points in the build Binaries\Debug\Microsoft.VisualStudio.Text.Data.dll may refer to Dev14 and at others it’s Dev15. If this seems like a scary proposition for a build that’s because it is indeed scary and it has real consequences. By now pretty much everyone on the team has hit the build race condition that is dragging down our PRs.

The general fix here is to move build outputs into separate directories. Instead of building to $(Configuration) projects now build into say $(Configuration)\Exes\$(MSBuildProjectFileName). This will have a substantial increase in the size of Binaries. We will be looking into ways to reduce that. In the short term though build stability far outweighs the size increase.

This change takes us most of the way to "correct". There are several places I had to compromise in order to get this initial change in:

- UnitTests still build to a common output folder (one for Dev14, another for Dev15). Pulling unit tests apart is going to take a bit of work.
- Every project has a <RoslynProjectType> entry. This will go away in the future for most projects. It's temporarily needed so I can fix roslyn-internal in parallel without taking down the build.
- VSL.Imports.targets is messy. Unavoidable for now due to the above. It will get cleaner as I iterate on this.

None of these are relevant to the underlying race condition. Hence it's okay to push them off.

* Update facades in VSIXes

* Add System.IO.Compression to the signing list

This change drops support for .NET 4.5 and retargets to desktop
4.6 + CoreCLR. It also fixes up various analyzer warnings that
were created due to the move.

Fixes #12926

Now that we specify codebase attributes in our binding redirections,
we don't need this anymore. This allows ngen to work in more scenarios
since it resumes loading our packages in a Load context.

I leave our diagnostics window VSIX as is, since that's a debugging tool
and it's less to maintain by keeping it that way.

The ImportGroup element is just noise.  It was also used very inconsistently in the repo and often within the same project file.  Just remove it.

* Enable building and testing on machines with only Dev15 Preview 3 installed

1. Auto-detect the VS common tools path
2. Convert analyzer samples to import Roslyn targets
3. Ensure dependencies are copied to the output directory
4. Workaround: Use local Microsoft.Net.Compilers.props until we move to a compiler toolset with https://github.com/dotnet/roslyn/commit/05c12ebfcdd08a02dbceded5327a8da7a7df23be
5. Replace references to Microsoft.VisualStudio.ComponentModelHost.dll (VisualStudioReferenceAssemblyVersion) with a nuget reference to RoslynDependencies.Microsoft.VisualStudio.ComponentModelHost
6. Add nuget references to Roslyn.Microsoft.Build, Roslyn.Microsoft.VisualStudio.ExtensionManager, RoslynDependencies.Microsoft.VisualStudio.Diagnostics.PerformanceProvider and RoslynDependencies.Microsoft.VisualStudio.CodeAnalysis.Sdk.UI.

* Remove workaround now that new NuGet packages have been uploaded to nuget.org

* Remove preprocessor directive MSBUILD12 and its references

This brought along some references to Microsoft.VisualStudio.Threading
that we previously didn't have. Nothing was wrong with this, but it
meant I had to fix some namespace qualifications that were assuming the
"Threading" namespace was unambiguous.

Back in 84d7856e, I updated our targets to always include all
dependencies from NuGet packages in our VSIXes. This was quick, but had
a few problems:

1. we would force-include everything, including VS SDK assemblies
2. we would include the same assembly in multiple VSIXes, even when
   we really didn't need them.

This is mostly a change to address the former. Now you have to
explicitly state which NuGet packages you do want to bring in, and only
those will get brought in to your VSIX. The rest are excluded.

This fixes the ability to build with later versions of Visual Studio
on your machine, since some later versions are incorrectly embedding
type forwards to assemblies that they shouldn't be. The NuGet package
includes dependencies of

- Microsoft.VisualStudio.OLE.Interop
- Microsoft.VisualStudio.Shell.Interop
- Microsoft.VisualStudio.TextManager.Interop
- Microsoft.VisualStudio.Shell.Immutable.11.0

automatically, and so I remove those from the project files now too.

For the Shell binary, we have two choices. We could either reference the
version that matches the version of Visual Studio you are building with,
or we could reference a fixed version with a HintPath so we can find the
binary on all versions of Visual Studio. Doing the former is tricky
since the name of the assembly is embedded into some XAML, so I go with
the latter option.

Moves the build task code to a shared project that we use to build
at net45 and a portable50 CodeAnalysis MSBuild task. Also upgrades to
nuget v3.2.1-rc since this is necessary to understand the dotnet4.3 spec
used in the project.json.

...to Roslyn.VisualStudio.Setup.vsix

The official build flag specifies which assembly version is baked into
Roslyn. This was being used in various ways to either include or not
include binding redirects, but we now always want binding redirects.
Also, we were passing the flag along to the compiler to figure out
which NewVersion to bake into the redirects, but setting nothing
at all conveniently does exactly what we want.

...to Roslyn.VisualStudio.Setup.vsix

These were added to work around a build problem, but the original
problem has since been addressed.

(This reverts commit 35f5cbad.)

MSBuildTask.

We don't need SolutionDir or RestorePackages, which were for very old-
style restore systems.

Update 1 defaults to copying implementations for some class libraries, but we
don't need that for our feature binaries.

Now that we specify CodeBase attributes everywhere, we can remove this.

Previously, our binding redirects were never specifying CodeBase
attributes, and relying on us being added to the BindingPath via
pkgdef. Unfortunately this mechanism doesn't work reliably if there
are other conflicting binaries in PrivateAssemblies, and so we should
specify CodeBase attributes whenever we're not producing a VSIX
that is being embedded in our shipping MSI.

Rather than update each of our ProvideBindingRedirectionAttribute
uses with another condition, I've replaced them all with a new attribute
that specifies the (indentical) values in one place. This is just for
ease of code maintenance rather than some technical necessity.

* This updates all references to nuget.exe to use the copy in the root.
* This deletes all NuGet.config and NuGet.exe files that are not in the root.
* This removes all references to NuGet.targets (which is obsolete and no longer exists)

The targets files were previously split into an open version in
Microsoft.CodeAnalysis.Toolset.Open and a closed version in build/. This
unifies the four targets into two new targets, VSL.Settings.targets and
VSL.Imports.targets, and moves all the targets from ..Toolset.Open into
the build/ folder.

System.Composition.Convention|Hosting|TypedParts
System.Collections.Immutable
System.Reflection.Metadata

Only restored to Roslyn.VisualStudio.Setup.vsix

Recently, a change was made to exclude assemblies that are part of Visual
Studio from all VSIXes.  However, VSIXes that are to be included obviously
need to be able to include such assemblies, so we use the new
ForceIncludeInVsix element to override the filtering.