This reverts commit e16d38bc.

     Background:

     As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

     https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

     The coding style transition is automated using a Roslyn based rewrite tool:

     https://github.com/dotnet/codeformatter

     This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

     Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1408227)

Use a compatible MethodInfo when generating MethodCallExpressions for virtual methods on value types.

When generating a call to a virtual method on a value type, the least overridden method virtual method is only used in special circumstances. These circumstances are exactly the checks performed by MayUseCallForStructMethod during IL emission when deciding whether or not to call a method with a value type receiver directly). This change applies the same rules when generating MethodCallExpressions for value type receivers in expression lambdas, bringing the generated code back in line with Dev12.
***NO_CI***
 (changeset 1394691)

Implements a new approach to generating unique synthesized member names (see also the attached email).

     1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique.
     2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead.
     3) Removes GenerateTempNumber from TypeCompiationState. Combination of method ordinal and other indices is used to make generated names unique:
     - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name (it;'s simple named "c<>").
     - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method).
     - The same for fields caching lambdas.
     - Dynamic site containers - no longer include method name in the type name, instead method ordinal is used.

     4) Expression compiler - rename generated type to "<>x" to avoid confusion with "<>c" static display class.
     5) Avoid replacing "." with "_" in member names, other than type names. While displaying stack frames the EE extracts method name from synthesized lambdas method names and displays it. Thus we were displaying "I_F" instead of "I.F" for explicitly implemented methods.
      In type names replace "." with "-". Replacing with "_" lead to duplicate type names in emitted assembly (2 iterator methods with names "I_F" and "I.F" - explicitly implemented iface method). (changeset 1390962)

A property's own {get,set} method was always being used when lowering property accesses in expression trees. This is incorrect in the face of partially overridden properties: the fix is to instead use the own or least overridden property accessor.

I also went ahead and fixed up a few other places in the codebase that were either not accessing the correct accessor or inconsistently accessing the correct accessor.
***NO_CI***
 (changeset 1380961)

***NO_CI***
 (changeset 1380516)

Search base types for operator {true,false} when binding user-defined short-circuit logical operators for compatibility with Dev12.

While making this change, I noticed that flow analysis was incorrect for lifted user-defined short-circuit logical operators; I've fixed this issue as well. (changeset 1376827)

Preparation for hoisting more locals in Debug builds. I noticed we can use less maps while rewriting a method to a class.

     MethodToClassRewriter:
     - parameterMap could be moved up to LambdaRewriter since it's only needed when rewriting lambdas.
     - variablesCaptured is replaced by a virtual NeedsProxy method which is implemented on LambdaRewriter and StateMachineRewriter using existing maps (so we can save another HashSet).
        We can also distinguish between "captured" variables and variables we create proxy field for. The former are deduced from syntax. A variable may be captured but not lifted into a field (e.g. expression tree lambda parameter). Or a variable can be lifted to field but not captured (in Debug builds we are going to lift user defined variables that are not captured to allow their later capture during EnC).

     LambdaRewriter:
     - variablesCaptured encodes the same information as keys of captured syntax multi-dictionary.
     - declaredInsideExpressionLambda is not needed either. When visiting ET lambdas we used to add their parameters to both variableBlock and declaredInsideExpressionLambda maps. Since ET lambda parameters are never lifted to closure we can avoid adding them to variableBlock map instead of excluding them later via declaredInsideExpressionLambda lookup.

     Adds internal IReadOnlySet similar to IReadOnlyList and IReadOnlyDictionary so that we can specify an intent of not mutating a set. (changeset 1317999)

Reduce the variety of optimization related compilation option values used in tests to: Release, DebuggableRelease and Debug.

By default tests should use Release, which enables all optimizations.
PDB tests should mostly use Debug.
We should have targeted tests for DebuggableRelease, for optimizations that are selectively disabled to improve debuggability of release builds.

   (changeset 1312277)

To support EnC well the compiler needs to carefully distinguish between long-lived and short-lived synthesized variables. Long-lived variables may cross sequence points and thus need to be mapped the the corresponding variables in the previous generation when emitting EnC deltas. Short-lived local variables shall never cross sequence points.

This change revisits helpers that create synthesized variables and assigns each synthesized variable a SynthesizedLocalKind. Negative kind values are reserved for short-lived variables, positive values for long-lived variables.

The change removed the option to give a synthesized variable an explicit name. The names of the variables are assigned at code-gen time based on their SynthesizedLocalKind. This is to enforce that the names of long-lived variables follow a naming pattern that allows use to reverse-engineer the SynthesizedLocalKind value from the variable name.

Also renames DebugInformationKind.PDBOnly to DebugInformationKind.PdbOnly to follow .NET naming guidelines.
 (changeset 1293017)

Bug fix #957927: Translate parameter types for a lambda that becomes a part of an expression tree.  (changeset 1286735)

Migrated state of “Declaration Expressions” implementation equivalent to https://roslyn.codeplex.com/SourceControl/changeset/b7fd08a5695e21cd4d23b8b70815c53656dab65f. (changeset 1249879)

...unless they're defined in the current compilation (via VB embedding).

Note: We originally wanted to reject constrained type parameters, but that would have blocked Interlocked.CompareExchange.

Bonus: SourceNamedTypeSymbol.IsRestrictedBaseType should check the SpecialType property, rather than performing a series of equality tests.

CR: AlekseyT (changeset 1215066)