Creates a new package, Microsoft.NETCore.Csc, which contains a Csc
binary compiled against the netcoreapp1.1 shared framework. This can be
installed as a NuGet package and built using the dotnet SDK, as long as
the netcoreapp1.1 framework is installed.

This change also downgrades a few packages, like
System.Diagnostics.FileVersionInfo, that were higher than the
version available in netcoreapp1.1.

# Conflicts:
#	src/Compilers/VisualBasic/VbcCore/project.json
#	src/Tools/Source/CompilerGeneratorTools/Source/BoundTreeGenerator/project.json
#	src/Tools/Source/CompilerGeneratorTools/Source/CSharpSyntaxGenerator/project.json

The description of this package is vague and incorrect. We now require .NET 4.6, not
.NET 4.5, and that is only a build-time requirement, not a deploy requirement.

We accidentally shipped a 2.0.0, so we'll have to bump the versions
for the rest of the 2.0.* series.

Something tells me this was copied out of Setup.proj that I wrote ages
ago...

Right now it definitely doesn't build due to pre-release dependencies,
and it's not clear that we'd ever ship non-pre-release versions out
of this repo (or at least versioned with the rest of Roslyn.)

* Add missing facades to devdiv toolset

Fixes http://ddweb/buildstatus/issues/issues.aspx?iid=819217

**Customer Scenario**: Referencing the latest Microsoft.Net.Compilers package and try to run csc.exe on Mono fails. (This was
found building the xplat branch of MSBuild.)

**Summary of Change**: Don't use System.Runtime.InteropServices.RuntimeInformation in Compiler, Workspace or Features layers

**Details**: Recently, we took a change to use `System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(...)` to detect the
current platform. The API is designed such that different implementations are delivered via NuGet depending on the TFM. For .NET
Core, this works great. When restoring an app using Microsoft.CodeAnalysis on Windows, a Windows implementation is delivered. And,
when restoring the same app targeting macOS/Linux, a Unix-specific implementation is delivered. However, for apps targeting
.NET Framework (such as the desktop compiler), this design presents a serious problem. Essentially, the Windows implementation
is always picked for .NET Framework apps (such as net451, net46, etc.). So, if that app is then run on macOS or Linux on Mono,
Microsoft.CodeAnalysis will *think* it's running on Windows and start reporting errors because path separators are pointing the
wrong direction.

Updating the Microsoft.VisualStudio.IntegrationTest.Utilities.nuspec to include Roslyn.Services.Test.Utilities

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

For the set of assemblies we build on *NIX, we should also be able to
build the coresponding nupkgs so they can be used by other repositories.

On *NIX we have a case sensitive file system, so we need the correct
casing in the .nuspecs.

Updating the Workspaces.Common nuspec to explicitly partition the desktop vs netstandard dependencies.