Fixes #13926.

Fixes #4903.

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

Fixes #1029

While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.

After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.

This adds a per-rule Title for all C# and VB compiler warnings that have message strings.  These Titles will show up in the ruleset editor.

This also includes Descriptions that show up upon expansion for a set of high-hit C# warnings.  I added Descriptions for high-hit warnings per MSDN.  The work is still pending to add the equivalent VB warning Descriptions.

The principle was to basically restate the base Message string without its fill-ins as the Title, swapping in general words such as "method" and "type".  Often, just removing the fill-ins and quotes was enough, as the surrounding context already said what the code element was.  Sometimes the message needed to be reworded a bit.  I also left out any further clauses (such as "Consider ..."), except for shortened versions necessary to disambiguate similar warnings.  For now, I'm leaving such clauses in the messages themselves, using Description for longer-form explanations - we can see if we get feedback there.

This should be the content work needed to ship the ruleset editor without blank titles.  There was one key bug remaining (now filed) where rules kept around solely to make previous /nowarns and #pragmas happy still show up in the ruleset editor.

Remaining work:
* Descriptions for VB compiler warnings
* Titles/Descriptions for C#/VB compiler errors
* Categories for VB/C# compiler warnings/errors (changeset 1387213)

VB: Overloadable members from unrelated interfaces should no longer trigger an ambiguous lookup error. Fixes #34. (changeset 1360454)

***NO_CI***
 (changeset 1356181)

Update assert in TypeUnification.CanUnify for substitutions from type parameter to type parameter (changeset 1354882)

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)

This shelveset implements following changes to metadata reference compiler API in order to remove duplication in the public surface and prevent users from unexpected metadata lifetime issues:

     1) MetadataImageReference and MetadataFileReference overlap
     Currently MetadataImageReference can be constructed from a Stream. MetadataImageReference supports metadata prefetch (reading the blob into memory and close the underlying stream) as well deferred reading (no content is read until the reference is consumed during compilation). MetadataFileReference only supports deferred reading.

     Lifetime of MetadataFileReference is non-deterministic, the underlying file is locked until no references exist and we GC the metadata.  On the other hand, it is possible to construct MetadataImageReference in such a way that allows controlling the underlying resources deterministically.

     Remove MetadataFileReference, use MetadataImageReference instead.

     2) Lifetime management
     AssemblyMetadata and ModuleMetadata objects hold on resources and implement IDisposable. When using MetadataFileReference constructors and some MetadataImageReference constructors to create references the underlying metadata objects are created implicitly and the user doesn’t have a way to explicitly dispose them.

     Make MetadataImageReference constructors internal and instead add factory method GetReference on AssemblyMetadata/ModuleMetadata. The usage pattern is:

     using (var metadata = AssemblyMetadata.CreateFromXxx(…))
     {
         var compilation = CSharpCompilation.Create(syntaxTrees, new[] { metadata.GetReference() });
         …
     }

     In addition the shelveset makes MetadataImageReference internal and adds the following convenience APIs, that are not the most efficient but are very convenient, easy to discover and safe to use for customers that don’t wanna explicitly manage the lifetime of metadata objects. (changeset 1345987)

***NO_CI***
 (changeset 1341617)

Fix bug 925931: Report error BC36394 (The 'Main' method cannot be marked 'Async') at declaration stage. Many tests were updated that incorrectly targeted a compilation to executable, but did not provide Main method.
 (changeset 1339789)

     The feature is conditional on "experimental" language version. (changeset 1339783)

made compiler error message to not include namespaces in most cases. this should make parsing error message a bit easier. (changeset 1334448)