Changed generation of PrivateImplementationDetails to append module name only when dealing with netmudules.

The goal of module name apending is to avoid clashes when combining multiple netmodules into multifile assembly. When building a regular assembly, appending module name is not serving any purpose and just causes unnecessary metadata differences.

Also in this change - when we do apend the module name, replace '.' with '_' when that happens. For example when we build a netmodule and its name is Foo.Bar.dll
More complicated name mangling schemes were discussed, but at this point we will do a simple '.' --> '_' as the least destabilizing change which is still sufficient in the most common case of having dots in the module name.

Fixes #1430

so that there will be no conflict if they are used as netmodules
Fixes #1228

***NO_CI***
 (changeset 1356181)

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)

Ported changes from Lance Collins for improving the determinism of the compiler:
     1. Use deterministic name (hash of contents) for mapped fields for array initializers.
     2. Visit references from IL with ReferenceIndexer as the IL is serialized (which happens in a deterministic order) rather than based on the order of module.ReferencesInIL which is nondeterministic due to parallel method body compilation.
     3. Sort assembly attributes to account for attributes coming from multiple files in nondeterministic order.

Remaining issue of deterministic signature(Guid) for PDB is not addressed here. See 900646.
Compiler still does not produce deterministic MVID or timestamp by default. (changeset 1314700)

We make the compilers (both C# and VB) deterministic (identical inputs cause identical outputs). In theory this may make distributed and incremental builds much easier to implement. It will also allow one to determine easily if any API has changed or not by simply generating a reference assembly and checking if it is identical to the previous one.

Two things needed to change:
(1) The timestamp in the header is replaced with 0 (which is specifically allowed by the spec)
(2) The module version ID Guid (Mvid) is computed by hashing the contents of the generated assembly (with zero
      where the Mvid will go for the purposes of computing the hash)

The name of the "private implementation details" class no longer includes the Mvid.

In order to simplify things, I removed the parameter from a few emit APIs where the caller provides the Guid for the Mvid. It turns out that nobody nowhere used it. So when emitting in the normal way, we don't know the Mvid ahead of time. For edit-and-continue, however, we always reuse the Mvid for the original assembly as before.

I implemented this assuming that everyone wants this new behavior. Some may worry that perhaps some unknown tool depends on the presence of the timestamp. I'd prefer to push it this way and see if anything breaks, because it will be simpler for it to just always work this way rather than having an option to turn it on and off. Also, I look forward to seeing if there is any performance impact due to running SHA1 over the whole in-memory stream. I suspect it will be unmeasurably small.

By the way, strong name signing happens after this is done, so there is no need to worry that a signature will introduce nondeterminism in the mvid. The strong name signature includes mvid in the data it signs. See Compilation.SerializeToPeStream to see the sequence. (changeset 1235486)