Bug (934091)  fix and additional coverage for conflict error messages when conflict between static local and local are defined with the same name

     Additional coverage added to ensure that single diagnostic is generated irrespective of order. (changeset 1242502)
Remove unused code in LambdaRewriter.InitParameterProxy (changeset 1243916)
Optionally assign original locals to lifted locals in LambdaRewriter (changeset 1244518)
DevDiv #924473: Inherited interface members in crefs

Crefs ignore inherited members, but I missed a few cases.

1) Binder lookup dropped them, but semantic model lookup (totally separate code path) did not.
2) Base interface members were dropped, but System.Object members were not (except with recovery code during binding). (changeset 1245954)
We need to be more conscious about producing synthesized symbols during lowering in order to enable EnC of method bodies whose lowering produce such symbols (e.g. lambdas, iterators, dynamic sites, etc.).

     This change refactors synthesized symbols in C# so that all symbols produced during lowering phase implement an interface (ISynthesizedMethodBodyImplementationSymbol) that can be used in the emit phase to retrieve information necessary for updating the corresponding metadata entities should they enter EnC.

     I also attempted to somewhat improve and increase consistency of the naming of synthesized symbols involved in this change.

     No new functionality is added by this change. (changeset 1247789)
Renames Emit.Context to EmitContext and removes unnecessary namespace qualifications of EmitContext and Cci types. (changeset 1248215)
When ArrayInitializerExpression is a local variable/field initializer, GetTypeInfo should return ConvertedType equal to the array type of the symbol being initialized. Fixes #116. (changeset 1248307)
DevDiv #909480: Implement RetargetingFieldSymbol.AssociatedSymbol (changeset 1248389)
Perform method group conversion validation when an instance of a delegate type is passed as an argument to a delegate constructor. (changeset 1248441)
This deals with bug 552717: C# IntelliSense: 'case' shouldn't appear in completion list after 'goto '.
It stops showing 'case 0', 'case 1' etc. labels in goto statements inside a switch block. It also stops showing the 'default' *keyword* after such a 'goto'. (The symbol completion provider already shows it in intellisense if it's been defined, and it without this change we'd see two of these).

The compiler still reports some labels with a colon appended to the end for which I've logged bug 937141: Labels in a switch statement have the colon appended to the name of the label, e.g. 'case 0:', 'default:' (changeset 1248486)
Change usages of ImmutableList to ImmutableArray. (changeset 1248518)
Perf: use Type instead of string as dictionary key.

This avoids unnecessary calls to AssemblyQualifiedName. (changeset 1248550)
C#: Add support for /langversion:experimental. (changeset 1249042)
Fixet typo in a comment. (changeset 1249258)
Bug fix (687246, 687 373): globalization - pass proper culture information when calling some TryParse() and IndexOf() methods (changeset 1249342)
Fix problem with vb syntax serialization data. (changeset 1249355)
Add telemetry for Edit and Continue rude edits while debugging. (changeset 1249391)
EnC: MethodImpl entries should only be added if the implementing method was added (changeset 1249535)
     Implementation of conditional access operators -    ?. and ?[]

 Change Description:

     Implementation of conditional access operators ( ?. and ?[] )

     The grammar roughly looks like:

     expr ::= | ...
              | expr ? tail

     tail ::= | tailopt . id
     tail ::= | tailopt .$ id                        <---   this is NYI in this change
              | tailopt [ expr-args ]
              | tail ( expr-args )

     Note that the tail isn’t optional for invocation: there is no ?(…) operator.

     Interesting implementation points:

     == Parsing/syntax

     Syntax tree is right associative – it has the same topology as in the grammar. However I did not create special variants for all the kinds of syntax that could be produced by the parsing of the tail of accessors.
     I just use regular syntax nodes with exception of the topmost node that is the conditional access operator itself and the lower-leftmost node that textually starts the accessor tail.

     The root node looks like –

     ConditionalAccessExpression
     {
        ExpressionSyntax Expression;
        SyntaxToken OperatorToken;                  // always “?”
        ExpressionSyntax WhenNotNull;              // by analogy with conditional expression which uses WhenTrue
     }

     WhenNotNull is an ExpressionSyntax that represent the sequence of postfix operations conditionally applied to the Expression. These are regular InvocationExpressions, MemberAccesses, ElementAcesses – whatever postfix operators we have.

     The only special part about WhenNotNull is that the low-leftmost expression child is one of 2 special “binding” nodes – MemberBindingExpression, ElementBindingExpression.

     Binding expressions are entities which can start the chain of WhenNotNull . Textually they look like  -  “ .SimpleName“ ,  “[argList]” or “$Name” (when $ accessor is supported).
     Note that there is no InvocationBinding, since we do not allow () to start the chain of applications – you cannot do “a?(arg)”.
     The binding expression syntaxes are basically versions of corresponding member/element/dollar access expressions without receivers.

     R?.a.b(x).c

     Would parse as

         ConditionalAccess
       /         |         \
     R           ?          MemberAccess
                                 /    |   \
                       Invocation     .     c
                      /           \
                MemberAccess       ArgList{( x )}
               /        |    \
     MemberBinding      .      b
         |      \
         .       a

     The advantage of using regular syntax nodes on the right side is that semantical analysis “just works”.  Naturally, because of the topology, the API cannot ask nonsensical questions like - what is the type of subexpression “R?.a.b” ?
     Since “R?.a.b” is not a subexpression, there is no way to ask such question.
     It is however possible to interrogate member accesses – they are just regular member accesses (in both syntax and bound trees) so they naturally know their types etc…

     == Binding

     Binding of the tree above is fairly simple – I only had to add binding support for the left-lowermost binding nodes. And what comes out is really just regular access expressions with placeholder receiver.
     I cannot refer to the actual receiver since we are not evaluating it again.

     In terms of schema - Bound tree actually needed even fewer changes than syntax tree – the bound tree for the above expression is just a regular bound tree. It is isomorphic to the syntax.
     The only new bound nodes are the root BoundConditionalAccess and the left-lowermost placeholder receiver – BoundConditionalReceiver.

         BoundConditionalAccess
          /                  \
     <BoundExpr>         BoundMemberAccess {c}
                              /
                        BoundCall {b}
                       /          \
      BoundMemberAccess {a}        List<Args>{ x }
                    /
     BoundConditionalReceiver

     == Dataflow

     Dataflow considers BoundConditionalReceiver always assigned. However the whole WhenNotNull is reachable conditionally  - i.e. assignedVariables state is forked when going into WhenNotNull.
     “receiver is a const” situation is handled trivially. That is similar to the ?? operator but somewhat inverted.

     == Emit

     There are two ways to emit this :
     - In complex cases (nullables, async, expr trees) we lower the conditional access into a ternary with consequence being rewritten as0is with just BoundConditionalReceiver replaced by a temp for the receiver value.
     - In simple case (all reference types), we do not lower the node, emit of BoundConditionalAccess dups the receiver (thus avoiding an IL temp) , checks it for null and conditionally executes the the access expression.
     BoundConditionalReceiver is handled by emit by not emitting anything since it represents receiver value and that is on the stack already.
 (changeset 1249636)
In C# lowering of async method stored the state machine type on SourceMethodSymbol so it can later be used when emitting synthesized attributes of the method. This may cause issues when emitting the same compilation twice with different options that affect the state machine type.
     Instead we should store the state machine type to the current PEModuleBuilder. Rather then actually storing it there and adding a dependency on PEModuleBuilder to the attribute generation this change introduces ModuleCompilationState (similar to TypeCompilationState) and threads that one.
     This type is designed to be mutable during compilation (lowering) and immutable during emit. The idea is that all data currently stored in PEModuleBuilder that are produced during compilation and only read in emit could be moved there. Only emit specific data would remain on PEModuleBuilder.

     Also refactors Compilation.Compile to remove some duplication and make it cleaner.
 (changeset 1249664)