This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support.

This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion.

This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio.

Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)

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)