Casts to object can always be removed because the expression in an interpolation will ultimately be converted to object in order to call string.Format(...).

Responding to peer review feedback. Updated to never consider user
defined narrowing conversions unnecessary.

Fixes #3161 and Fixes #3163

User Scenario:
User has code with narrowing conversion with an explicit cast.  We will
offer to remove the cast even though this will cause the code to not
compile.

Fix Description:
We previously never consulted optionstrict to determine if a
user-defined narrowing cast was necessary.  The fix in CastAnalyzer.vb
will check if the conversion is narrowing, if option strict is on, or if
we generate a warning on implicit narrowing conversions.  We also offer
to add a cast if an implicit conversion warning is given.

Testing:  Added regression tests + existing tests

For code snippets such as below: "Base M(Base b) => (Derived)b;", we currently offer cast removal for cast to derived. However, this involves an explicit/narrowing conversion and hence can lead to an exception or data loss. The only way to detect such redundant casts is via flow analysis, which is not currently in our scope.

Fix is to bail out early for such cast expressions. I have also fixed incorrect tests that were added to ensure the current behavior.

Fixes #2761

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)

We offer cast removal for case where expression type and outer type are identical and cast to outer type is widening reference conversion. However, we also need to check if expression to cast type is not a narrowing reference conversion as that can cause cast removal to change the runtime value of the expression. I also fixed an incorrect test that was verifying the current behavior. (changeset 1362323)

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)