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.

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.

* 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)

...to include nuget references in the output VSIX.  This was broken with
the migration to project.json, because we no longer have a way to specify
<ForceIncludeInVSIX>true</ForceIncludeInVSIX> for nuget references.

My wild guess as to why the Workspaces dlls aren't signed in the Interactive
VSIX is that they're not marked "ForceIncludeInVSIX=true" (as most of the
other references are).

...in Roslyn.VisualStudio.InteractiveComponents.vsix.

This is preliminary work for Interactive setup authoring.

- Fix versions of InteractiveWindow and VsInteractiveWindow at 1.0.0.0 so
  as not to break existing consumers (e.g. Python Tools).
- Redirect consumers of the VsInteractiveWindow to 42.42.42.42 in the
  RoslynDev hive.
- Delete some unused Debugger stuff from VisualStudioInteractiveServices.
- RootNamespace and AssemblyName should match TargetVsixContainerName to
  avoid confusion.
- Don't deploy an extra copy of Microsoft.CodeAnalysis.VisualBasic.dll
  with Roslyn.VisualStudio.Setup.Interactive.vsix.

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.

The VsSdk changed to specifically exclude System.Collections.Immutable and
System.Reflection.Metadata from the output vsix so we'll have to mark them
<ForceIncludeInVSIX>true</ForceIncludeInVSIX>.

(fixes #3687)

It doesn't make sense to have both ReferenceOutputAssembly=false and
IncludeOutputGroupsInVSIX=BuildProjectOutputGroup.  (The upshot is that
the affected references end up in the VSIX unsigned.)

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.

This deletes the empty and unused Desktop assemblies from the code base.

This reverts commit 8cfc284c.

This reverts commit 0eba2636.

These extra properties should cause only the build outputs of the directly referenced projects to be included in the vsix(es).

(fixes #578)

This change moves the contents of VisualStudioSetup into the open,
merging with (and consuming) VisualStudioComponents. The Components/
Setup split originally existed as a way to allow multiple Roslyn-using
components to have a single source of truth of the MEF exports. This
meant you could have either the interactive window, language services,
or both installed and everything worked. This was important when we
were atop Visual Studio 2013, but now that we're integrated it's buying
us nothing.

The VSIX ID from VisualStudioComponents is preserved so that way any
extensions that declared a dependency on it will still work.