Ensure that all *.*proj, *.props, and *.targets files are prefixed with the xml and copyright elements

At this moment there is no supported way of building a portable DLL and deploying
current OS dependencies (say windows) as a default.  As a result these DLLs are
not full deployed post build (not runnable) and this breaks any number of
tools developers use to be productive: F5, TDD, WPF xunit runner.

Roslyn works around this for official builds by using deployment projects.  This
is a project per supported delpoyment (Desktop, CoreCLR) which consists of a
dummy EXE and referenes all of our portable DLLs.  Hence they DLLs as they exist
in that output directory are fully deployed.

This makes it possible to do official testing with confidence but doesn't developers
who want a more rapid feedback experience.

This change makes it possible to do direct testing again by adding an ad-hoc deployment
mechanism.  This uses the same code as the official deployments but is still ad-hoc
so it won't be used for official builds: just developer builds.

Here is the bug on MSBuild tracking the real bug and fix

https://github.com/Microsoft/msbuild/issues/1499

Our current setup for .Net Core requires us to do manual assembly redirection in our MSBuild Task.  The setup has no
good way to detect at compile time when our source code and NuGet references get out of date.  This change allows us
to at least detect at bootstrap time.

MSBuild generates the TargetFrameworkAttribute file to the same path on
disk for equivalent combinations of TargetFrameworkIdentifier and
TargetProfile.  This means if two projects in a solution have equivalent
identifiers, their builds will race to write the same file to disk.

This is safe by virtue that the content of the file is the same in both
cases.  Hence it doesn't really matter who wins the race, both projects
see the same output.

This is frustrating though because even though it's safe, MSBuild still
isssue a warning when it happens.  This breaks our desire to have
warning free builds.

To fix this we will instead generate the file to the Obj\ProjectName
directory.  This means every project gets their own indepnedent copy of
the file, eliminating the race.

closes #10116

This is a centrally controlled property.

This setting controls binary deployment hence it needs to be centrally
managed to help ensure we have a correct build.  Custom projects can
continue to control this setting themselves.

Updates the compiler used in the Linux and Mac toolsets and also
eliminates the requirement to download the toolset as a zip and instead
restores the necessary components over NuGet.

Portable unit tests are difficult because as portable libraries they can't truly be built in a runnable fashion.  Instead they need a deployment project to provide a runtime on which to delpoy the output of the build.  To support running our portable tests on both desktop and CoreClr the build is structured as follows:

- Portable tests build w/o deploy to a Dll directory
- Desktop delpoyment references all portable tests and outputs to UnitTests\Desktop\Portable
- CoreClr deployment references all portable tests and outputs to CoreClrTests

This breaks F5 for the moment but gives us the flexibility to restore later.

Ensure that we set the OptimizationDataFile path after importing the core targets, which sets $(TargetName) that is used by this property.

This allows build to succeed at installing the extensions, so that it's
possible to debug changes.

The wrinkles here are that:
1. SDK's before the RC one don't know how to install on RC.
2. The RC SDK *requires* a <Prerequisites> element
3. The Willow installer fails to install vsixes that have a <Prerequisites> element.

To workaround 2 and 3, if we detect that you are building with something before RC,
we run an xsl transform to remove the <Prerequisites> element before the SDK uses it.

Since our official builds for insertion into Willow are still on VS 2015, they won't
have the element.