We support dangling project references in the workspace API,
and the ProjectDependencyGraph is only supposed to return references
that exist within the project. Therefore, if we add a project, we have
to check to make sure we didn't have a dangling reference becoming a
real reference, and give inconsistent results.

I expect this to be a rare situation in reality so don't want to spend
a lot of time optimizing for it, but if it happens this will keep
everything in sync.

Some of these are particularly hard; we have a lazy data structure that
has "I don't know" as something the algorithm needs to deal with.
Unfortunately trying to test through the public Solution APIs often
doesn't work because the Solution code accidentally asks the dependency
graph for things which then invalidates the "I don't know" by causing
it to compute things.

Any time we made a change to the dependency structure of a solution,
we threw away the dependency graph entirely and recomputed it. This
was pretty wasteful, since we'd promptly recompute parts of it as
a part of the workspace solution forking. The allocations were quite
high, often to recompute the (almost) exact same immutable data as
before.

This adds the abilty to take an existing ProjectDependencyGraph and
update it to produce a new graph with project references added, which
reuses whatever data was easily available.

This will make it easier to assert intermediate states.

By not using the map, we can easily have helpers that can be called
by additional tests directly.

The code in CreateSolutionFromReferenceMap tried very hard to support
the ability that if you had the same project name with different
references, that we should merge all the different references together
For example, "A:B A:C" should be equivalent to "A:B,C". But if you
tried this, it would have crashed anyways becuase we'd see a duplicate
project name. Since it doesn't work, no reason to keep it around.

We support dangling project references in the workspace API,
and the ProjectDependencyGraph is only supposed to return references
that exist within the project. Therefore, if we add a project, we have
to check to make sure we didn't have a dangling reference becoming a
real reference, and give inconsistent results.

I expect this to be a rare situation in reality so don't want to spend
a lot of time optimizing for it, but if it happens this will keep
everything in sync.

Some of these are particularly hard; we have a lazy data structure that
has "I don't know" as something the algorithm needs to deal with.
Unfortunately trying to test through the public Solution APIs often
doesn't work because the Solution code accidentally asks the dependency
graph for things which then invalidates the "I don't know" by causing
it to compute things.

Any time we made a change to the dependency structure of a solution,
we threw away the dependency graph entirely and recomputed it. This
was pretty wasteful, since we'd promptly recompute parts of it as
a part of the workspace solution forking. The allocations were quite
high, often to recompute the (almost) exact same immutable data as
before.

This adds the abilty to take an existing ProjectDependencyGraph and
update it to produce a new graph with project references added, which
reuses whatever data was easily available.

This will make it easier to assert intermediate states.

By not using the map, we can easily have helpers that can be called
by additional tests directly.

The code in CreateSolutionFromReferenceMap tried very hard to support
the ability that if you had the same project name with different
references, that we should merge all the different references together
For example, "A:B A:C" should be equivalent to "A:B,C". But if you
tried this, it would have crashed anyways becuase we'd see a duplicate
project name. Since it doesn't work, no reason to keep it around.

This change reduces confusion on the intended use of this workspace which is primarily for testing or doing analysis outside of a host environment without requirement to round-trip changes to disk. (changeset 1396090)

This property controls what happens when referenced projects are not recognized as supported project types during solution or project open. If set to false, an exception is thrown the first time an unrecognized project is encountered.  If set to false (the default) it raises an WorkspaceFailed event and continues, omitting the project from the resulting solution and leaving dangling project references.  Of course, if the project type is unrecognized but its metadata can be identified, the project reference is turned into a metadata references (as per existing behavior).

Added tests for all cases of unrecognized projects; bad path, non-existing project file, unrecognized file extensions, unrecognized project type and unrecognized language.

Updated HostWorkspaceServices to allow for searching for language services without forcing the language to be loaded.  Added ProjectFileExtensionAttribute and ProjectTypeGuidAttribute so ProjectFileLoader's can declare via MEF metadata information used to find them.

Removed Project GUID from ProjectFileReference.  Project GUID's cannot be trusted. :-)
 (changeset 1279722)

FeaturePacks have changed to become HostServices.
IWorkspaceServiceProvider has become HostWorkspaceServices
ILanguageServiceProvider has become HostLanguageServices

HostWorkspaceServices can be accessed directly from Workspace.Services.
HostLanguageServices can be accessed directly from Project.LanguageServices.

Some of the existing workspace and language services have been made public. (changeset 1226729)

for now, it only contains Formatting Tests, but in future, we should split mixed lang tests in service test to each own one. (changeset 1223390)

This changes removes the ProjectDependencyService and replaces the Solution's itnernal transitive dependency tracking with the ProjectDependencyGraph.  After the change removing async projects from solutions, the service was no longer necessary, as dependency graphs (mostly on demand) can be computed and reused for most solution branching.  The solution's internal transitive dependency tracking then became redundant. (changeset 1210210)