- VB: Report a warning about AssemblyKeyFile and AssemblyKeyName attributes being ignored by public signing.
- Disallow public signing for Net modules. The fact that the signing is public is not preserved in a module. The fact of signing is preserved by emitting attributes that are going to be ignored anyway if public signing is used.

Closes #11427.

The Compilers.sln solution is compiling again and tests which don't
require AppDomain support are running again.  There is a bit of work
that is needed for AppDomains that I want to separate out.  In
particular the separation to portable means we have to redo some of the
serialization code.

The previous code mistakenly put the TupleElementNamesAttribute on the
type ref for interface implementations and type parameter generic
constraints. This change moves the attribute to the actual interface
implementation and constraint handles, where it belongs.

Fixes #14844

Fixes #14267.

Add a test for assembly level attributes in NetModules in absence of AssemblyAttributesGoHere types.

Related to #10550.

Local functions previously used the local function name but, as local functions
are not members, this was inappropriate.

Fixes #13268

Roslyn uses the CLR APIs to sign an assembly, so as long as the CLR
supports the key length and it is a valid key structure there's no
reason we should limit the length of the key. In addition, the previous
limit was wrong -- it didn't include padding space for the key header.

Fixes #12822

Addresses #12347 

Currently, if you implement an interface with a tuple type as a
substituted type argument that will be accurately represented in source,
but the names will be lost when emitted to metadata.

This PR implements roundtripping for tuples as generic type arguments to
interface implementations in metadata. This is done by adding support
for emitting attributes on interface implementations to Emit. We now
emit the same attribute on interface implementations that we would
on other areas where types may contain nested tuples. Completes the
interface implementation work referenced in #12347.

Previously, a tuple in a declaration context always required a
TupleElementNamesAttribute to record the names. Now, when the tuple has
no names the compiler will elide the attribute. On loading from
metadata it is assumed that tuples without an attribute have no names.

Fixes #12454

For the most part, this change implements the same encoding
for tuples that we use for dynamic. This means that interface
implementations and generic constraints are not covered, but
base types and type parameters are.

This change also doesn't have full tests for "long" tuples (nested tuple
transformations) or tuple types that can only be constructed in
metadata.

* Bug 217740: Repro and test harness for C#

* Testing and fixing loading scenario in C# and VB

* Verifying VB case using attribute on field

* Adding more tests

* Adding VB tests

* Adding tests

* More tests on fields with double-attributes

* New test constraint

* Fixing VB side to new test constraints

* Fixing C# side to new test constraints

* Fixing remaining tests

* Adding comments

* Fixing VB field scenario too

So far compiler knows about the following signatures of DeprecatedAttribute constructor.
   DeprecatedAttribute(String, DeprecationType, UInt32)
   DeprecatedAttribute(String, DeprecationType, UInt32, Platform)
   DeprecatedAttribute(String, DeprecationType, UInt32, Type)

As of TH2 and onwards  Windows SDK  uses the following signature for the DeprecatedAttribute:

     DeprecatedAttribute(String, DeprecationType, UInt32, String)

Notice the "String" at the end of the signature.
This change adds the TH2 attribute signature to the known set.

Fixes: #10630

Do not report warnings for malformed InformationalVersionAttribute values

* remove old syntax tree root tests

* fix vb tests

Make compiler produce the same Product Build, Major, Minor and Private Parts in VersionInfo as VS2013 compiler when Assembly ProductAssemblyFileVersionAttribute and AssemblyInformationalVersion contain invalid format. Also introduce warning diagnostic for AssemblyInformationalVersion with invalid version string

Right now there are two code paths for signing using a keyfile:

1) Full & delay signing implemented using a strong-name provider, which
   calls into the CLR when necessary to do signing.
2) Public signing, which extracts the key directly from the file and
   embeds it manually into the assembly using only portable code.

The tricky part is that (1) also implements a bunch of legacy semantics
on how to resolve the key file from various search paths, since the key
file can also be specified via an attribute.

This behavior is already deprecated, so rather than implement the
complicated file resolution for public sign as well, this PR changes the
command line compilers to always produce an absolute path for the key
file before passing it to CompilationOptions. CreateCompilation now also
has a check to enforce that CryptoKeyFile is an absolute path when
PublicSign is set.

Fixes #8360.

Fixes #7387
Closes #7515