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 #8287.

Sometimes called "fake sign" or "OSS sign" public signing is including
the public key in an output assembly and setting the "signed" flag, but
not actually signing the assembly with a private key. This is useful for
open source projects where people want to build assemblies which are
compatible with the released "fully signed" assemblies, but don't have
access to the private key used to sign the assemblies. Since almost no
consumers actually need to check if the assembly is fully signed, these
publicly built assemblies are useable in almost every scenario that the
fully signed one would be used in.

This PR implements support only for C# -- VB will be added soon. If
being used at the command line, the /publicsign flag can be passed to
csc and the /keyfile flag can specify the public key. Unlike fully
signing, a full key pair encoded in the SNK file format is not currently
supported. When using /publicsign, just the public key must be in the
/keyfile file.

When using the API, the public key can be passed directly using the
CryptoPublicKey CompilationOption.

Previously, the unix root "/" would not be considered a valid
path for pathmap to map to.  This commit fixes that, adds a
test case, and adds diagnostics for unparsable pathmaps.

Add a new switch '/errorlog:' to VB and C# command line compilers to log all the compiler diagnostics into a log file.
Add command line parsing tests and error log content validation tests.

Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key

Due to CLR bug 1094313 the added members can't be referenced from another assembly. For now we report a rude edit if we detect a MemberRef or TypeRef to a symbol added during debugging.
 (changeset 1384081)

When we crack open an analyzer dll and instantiate analyzers, we can produce some warnings in faulty cases. These were being produced way to early and weren't being passed through regular filtering code. Such support didnt exist because we were only producing errors during this stage. We don't want these warnings to be errors. Adding some code to call into the CSharp\VBDiagnosticFilter type which has all the filtering logic based on options.

There were already a bunch of unit tests for this scenario - all recording the errant behavior. fixing them all up now. (changeset 1378577)

     Moves options that were previously on CompilationOptions but were not used until emit phase to EmitOptions: fileAlignment, baseAddress, highEntropyVirtualAddressSpace, subsystemVersion, runtimeMetadataVersion. They hold on values written to various PE headers. We can now easily add other similar PE flags to EmitOptions, which is a common customer request, without affecting code that works with compilation options in other layers (workspaces, project system, etc.).

     Removes EmitMeadataOnly method and instead adds a MetadataOnly flag to EmitOptions. Removes MetadataOnlyEmitOptions - they were not used and can now be easily added as bools to EmitOptions.

     Moves pdbFilePath and outputName from parameters of Emit to EmitOptions.

IDE: remove tracking of options that were moved to EmitOptions, since the IDE doesn't care about options that don't affect compilation. (changeset 1348623)

Address CR feedback for changeset 1272615 (Handle analyzer type load failures in a better way): Change the newly added diagnostic's severity to be an info rather than a warning.  (changeset 1272711)

Handle analyzer type load failures in a better way: If Assembly.LoadFrom throws a ReflectionTypeLoadException, our current behavior is to log a compiler warning and skip the analyzer assembly. However, this exception might be caused by some unrelated missing types in referenced assemblies and it is possible to continue looking for analyzers from the loaded types in the assembly. This change tweaks the behavior to now log a separate warning for a ReflectionTypeLoadException, and continues working with only the loaded types.  (changeset 1272615)

Replaces FileResolver with 2 types that are portable and implement reference resolution for specific feature. The goal is to have 3 resolvers total - one for each kind of reference to artifact that the source may contain
1) MetadataReferenceResolver
Resolves #r directive values.
2) SourceReferenceResolver
Resolves source references and normalizes source paths. Used by #line, #pragma checksum and PDB paths (and #load in script files, which is not implemented yet).
3) XmlReferenceResolver
Resolves references to XML documents in <include> and PermissionSet(File = "...")

Each resolver is also a provider of the resolved content. Currently that's not true for MetadataReferenceResolver, we have a separate MetadataReferenceProvider. I'll follow up with a change that merges these two.

In addition to the above resolvers CompilationOptions still have AssemblyIdentityComparer and StrongNameProvider. These remain unchanged.

The non-portable part of the compiler provides a file resolver for each reference resolver:
1) MetadataFileReferenceResolver (to be renamed to MetadataFileResolver)
2) SourceFileResolver
3) XmlFileResolver

these resolvers implement csc/vbc behaviors.

Default CompilationOptions don't have any resolvers. Thus the features that are dependent on these resolvers won't work and a diagnostic is reported. (changeset 1208519)