Now that the comment formatting issue is fixed in the Formatter type, we can run the formatter on the remainder of the VB code base.

closes #1424

Marks CSharpKind and VBKind extension methods as Obsolete and adds equivalent extension methods Kind for both languages.
Marks CSharpKind and VBKind instance methods on language specific syntax nodes Obsolete as well.
 (changeset 1389494)

Marks CSharpKind and VBKind extension methods as Obsolete and adds equivalent extension methods Kind for both languages.
Marks CSharpKind and VBKind instance methods on language specific syntax nodes Obsolete as well. (changeset 1388816)

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)

Abbreviates the public VB-specific types (e.g. VisualBasicSyntaxTree -> VBSyntaxTree) in accordance with the .NET Class Library Guidelines to avoid overly lengthy names and consistent with the conventions used in other APIs (e.g. VB CodeDom). (changeset 1348499)

AbstractCodeGenerationService.AddMembers was using an O(n^2) algorithm to insert new members.  This change allows bulk inserting members if the AutoInsertionLocation flag is false.  For now, metadata as source only sets AutoInsertionLocation to false for enum symbols which can commonly have thousands of members.

SeparatedSyntaxList.InsertRange was also calling Insert for each node.  It now adds the nodes in a single step. (changeset 1344073)

There were many classes that would inherit other classes, but all methods being used were static methods. It appears inheritance wasn't being used to take advantage of a type hierarchy or for virtual dispatch, but just to scope helper methods. This is overkill and makes the code more difficult to understand.

Also, remove a few places where static methods were newing up objects that should have been singletons. (changeset 1326268)

This change adds the SyntaxGenerator class to the CodeGeneration API in the Workspaces layer. It can be used to create some common syntax nodes without needing to use the language specific syntax factories.

This functionality was previously internal and named ISyntaxFactoryService. (changeset 1314413)

Majority root cause was the fact that we were bypassing logic already present in the default Implement Interface code fix when implementing the dispose pattern. We were also failing to generate a blank line after generated close brace for classes in C# leading to problems when the generated close brace id follwed by directives.

I also discovered couple of other unreported issues and am fixing them up as part of this change -
- Case sensitive string comparison was being used in VB.  I changed this to be case-insensitive.
- We were simplifying the entire class (including code that user would have typed by hand) when implementing the dispose pattern. I have fixed this to only simplify the code that we generate.

Also fixing up a couple of comments based CR feedback for a couple of earlier unrelated fixes. (changeset 1297494)