Modified C# directive parser to allow #pragma warning disable/restore to take string IDs in addition to integers in order to generalize to user-generated diagnostics. Compiler-generated diagnostics all have integer error codes in addition to a string ID, but user-generated diagnostics are only identified by a string ID. This change also affects the language grammar, effectively changing the grammar of "warning-list" in section 2.5.8.1 of the C# spec from:

warning-list:
    decimal-digits
    warning-list   whitespaceopt   ,   whitespaceopt   decimal-digits

to:

warning-id:
    decimal-digits
    string-literal

warning-list:
    warning-id
    warning-list   whitespaceopt   ,   whitespaceopt   warning-id

As implemented, the compiler will accept the following:

#pragma warning disable ?CS0168?
#pragma warning disable ?CS0168?, ?CS0219?
#pragma warning disable ?CS0168?, 219 // , ... etc.

And warn about the following:

#pragma warning disable ?CS168? // warning CS1691: 'CS168' is not a valid warning number
#pragma warning disable 1 // warning CS1691: ?1? is not a valid warning number (current behavior)

Only strings that match 'CS[0-9]*' are assumed to be compiler diagnostic IDs, so the compiler will not warn about something like:

#pragma warning disable "CS1MyWarning" // This could be a user diagnostic ID (changeset 1209083)

Make it possible to update CompilationOptions with new specific diagnostic options, rather than having to go through CSharpCompilationOptions or VisualBasicCompilationOptions to do this.

This is a public API change. (changeset 1208990)

PERF: Reduce SourceLocation allocations by avoiding the .Location property on SyntaxReference where possible. The .Location property was changed to a GetLocation() method to indicate that it carries a peformance cost.
This accounted for 3% of allocations in the C# typing perf test. The same change was made in VB for completeness, although the impact was much less in the VB typing scenario. (changeset 1208921)

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)

The key difference is that HasIdentityConversions ignores object/dynamic distinction. (changeset 1208214)

Refactor ruleset parsing and diagnostic analyzer assembly resolver code in the shared code analysis project so that it can be re-used by workspaces layer for ruleset files and analyzer assemblies specified in the project files (user story 900556: Workspace support for analyzers\rulesets). (changeset 1208161)