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.

Tuple element names CDI refactoring 

We leave the assembly version at 2.0.0 since that's what we do for patch
releases.

This makes two changes:

1. Move us to GitLink 3.0
1. Add source link info to all binaries we sign

That package is the exact same contents as 0.10.6-rc2 but just repacked.

We've shipped -rc4 packages to nuget.org, so any future builds should
be versioned higher.