This reverts commit 28c8c78d.

We don't need the split anymore now that we're only supporting Dev15.

Unfortunately this required the introduction of a NuGet package that
has a namespace "Workspace" to our VS project, which meant I had to
disambiguate Workspace wherever it's used in that layer. I considered
doing an extern alias instead to disambiguate, but applying that to a
ProjectReference isn't supported. That's tracked by NuGet/Home#4989.

ForegroundThreadAffinitizedObject had a instance field which was the
foreground thread state when the object was created. There's no reason
to hold onto that, as the only reason it could change is if we captured
the wrong thing to start with. This also supported the ability to
explicitly state the foreground thread, a reason which was entirely
unneeded since the only use in the codebase had set the static state
the line before.

Previously, when a VisualStudioWorkspace was constructed we were
doing a bunch of work in the constructor talking to the UI thread. This
was dangerous because we might get composed on a background thread.
This moves the dangerous initialization until we're creating a project
when we know we have a UI thread available.

In this refactoring I moved the project tracker and a few other fields
into a private class so it's more obvious what's dangerous to touch.
I also do a pass through all consumers of the property and either
update it to use the deferred state directly (because we're only
consuming projects, so it's fine if we don't have anything) or to the
factory method if we actually are creating projects.

This does temporarily regress the ability to create projects on
background threads, but it was unclear if that was generally safe to
start with.

Create a code fix that offers to add a reference to System.ValueTuple if it is missing and you use a tuple.

The important part is that we don't create these services until they are needed.
We don't need complicated logic about later on disabling them.  The current logic
attempts to disable them when the same packages that loaded them, get unloaded.
But packages only get unloaded when VS is shutting down. And we don't need to
do complex work in that case as our entire environment is going away.

--

In other words, we had complexity around returning teh service to an 'unstarted'
state just so it could be started up later.  But it will never be the case that
we'll ever start the service up again as the only reason we moved it to 'unstarted'
was because VS was shutting down.

The important part is that we don't create these services until they are needed.
We don't need complicated logic about later on disabling them.  The current logic
attempts to disable them when the same packages that loaded them, get unloaded.
But packages only get unloaded when VS is shutting down. And we don't need to
do complex work in that case as our entire environment is going away.

--

In other words, we had complexity around returning teh service to an 'unstarted'
state just so it could be started up later.  But it will never be the case that
we'll ever start the service up again as the only reason we moved it to 'unstarted'
was because VS was shutting down.

To enable the feature set the following DWORD regkey to 1:
Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<your hive>\Roslyn\Internal\OnOff\Components
Name: PackageSearch

To disable, set it to 0.