The VS SDK team provided us with an updated NuGet that has better error
diagnostics during install / uninstall.  Going to change our VSI tests
to begin using build based deployment again for VSIX until they can get
the diagnostics that they need.  Once they have them will flip it back.

The VS SDK team is interested in tracking down the deployment errors
that we are seeing when deploying as a part of build.  This change adds
an option to make it easy to excercise that code path in builds.

Going to use this option to quickly toggle to the build based deployment
in order to mass test their fixes.

The Net20 framework projects were accidentally depending on 3.5
framework in order to build.  This is due to how they generate
resources.

By default when generating resources for a 2.0 framework project the
MSBuild task from 3.5 was being used.  This is not installed by default
with Visual Studio and only through the 3.5 framework.

This went unnoticed when moving to the new SDK because all of the
Jenkins machines and @jaredpar machines have it installed.

Setting the `$(GenerateResourceMSBuildRuntime)` property to
CurrentRuntime will use the GenerateResource task from the current
version of MSBuild.  This is how resources were being generated before
the migration.

This was reverted as a part of 5fe4adb3 but should have been
put back.

The Microbuild leg now almost completely builds.  It's failing in the
validation of our compilers Nuget package.  This comes from subtle
changes to Toolset.csproj that need to be addressed.

This does represent a huge step forward though.  Saving this now so I
can experiment with that change.

The content produced by NuGet restore is independent of build
configuration.  Hence it needs to be stored in a folder that is
accessible to both Debug and Release.

This didn't work with the present structure of our Obj directory
because it put project folders under configuration directories.  That
mean there is no common parent for a project across all configurations.
To fix this we need to change our Obj structure:

- Old: `Obj\<Configuration>\<Project Name>`
- New: `Obj\<Project Name>\<Configuration>`

This changes our NuGet download and commits us to package reference
elements.

Create the Packages.props and FixedPackages.props.  These are the files
which will contain our MSBuild mapping from packag name to package
version

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.

Based on discussions with SDK team, attempting to switch to using
`$(OutputPath)` for controlling our output directory instead of
`$(OutDir)`.  This is how the SDK recommends teams do it and need
to validate whether this will work for us or not.

In order to leverage LUT testing we need to have both of the
follownig packages in our build.

- xunit.runner.desktop
- xunit

Both of these include xunit.abstractions.dll in different forms: content
and reference respectively.  This creates a double write violation in our
build.

I've spoken with the xunit team and at this point they believe the
feature is executing as designed.  The content use in xunit.runner.desktop
is meant to support 1.X clients who can't reference the package.

I'm still working with them to find a better way to exclude this but
for now this will remove the race in our build.

Issue #18573 will remain open to track the handling here and find
a better solution.

There is no good method today for executing windows commands with
dynamically built argument lists in Powershell.  This change attempts
to address that by introducing Exec-Command which uses the .NET
Process API directly.  This makes it straight forward to build windows
commands that rely on windows style parsing and output

At this point the Concord project exists just to fix a signing issue in
the Debugger NuGet packages.

This project is causing problems in our port to the new SDK because it's
a Net 45 portable project that is referenced by Net 20 projects.  The
old build silently ignores this incompatibility but the new SDK takes
issue with it, and the method it uses to pass DLLs around.

Taking the simpler approach here of just fixing the signing issues (side
thread going with debugger team) and removing the project.

Some NuGet targets also use this property and they expect a trailing
slash to be present

The motivation for this change is to simplify our build and develop
steps.

Previously our compiler builds included files generated into the Obj
folder during previous phases of the build.  This meant that in order to
open Roslyn.sln successfully the code needed to be built first.  Not
ideal.

The generated code involved is rarely changed.  But in order to build
the generators themselves must be built and run as a part of every
build.  This is doable but adds unncessary overhead to development and
complicates our build files a bit.

This approach checks in the generated files which should have the
following benefits:

- Roslyn.sln can be open after a restore
- Build process is simplified and marginally faster for many operations
- Generated code now participates in GitLink

Removes our reliance on the machine installed reference assemblies.
Preferring the ones which we bring with us to the machine for both
Windows and Linux.