Fell out of our normal cadence for this during the push for RTM. Now that we
had a bit more breathing room getting us back on track here.

Definite assignment, generic iterators, symbol display, and parser fixes

Fixes #2549

This happens since setting next statement skips the closure initialization, which marks as hidden sequence point.

In this PR, we emit a regular sequence point instead of a hidden sequence point to closure initialization whenever necessary, so IP move won't skip closure initialization.

Variables may have been captured by lambdas in the original method
or in the expression, and we need to preserve the existing values of
those variables in the expression. This requires rewriting the variables
in the expression based on the closure classes from both the original
method and the expression, and generating a preamble that copies
values into the expression closure classes.

Consider the original method:
```
Shared Sub M()
    Dim x, y, z as Integer
    ...
    F(Function() x + y)
End Sub
```
and the expression in the EE: "F(Function() x + z)".
The expression is first rewritten using the closure class and the local
`<1>` from the original method: F(Function() `<1>`.x + z)
Then lambda rewriting introduces a new closure class that includes
the locals `<1>` and z, and a corresponding local
`<2>`: F(Function() `<2>`.`<1>`.x + `<2>`.z)
And a preamble is added to initialize the fields of `<2>`:
```
    <2> = New <>c__DisplayClass0()
    <2>.<1> = <1>
    <2>.z = z
```

(cherry picked from commit 505501bc38905a4389994d4452d56300e36c01db)

Categorize synthesized query lambdas
Make sure SynthesizedLambdaSymbol and BoundQeuryLambda has the same syntax

     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)

1) Change MethdCompiler.BindMethodBody to associate correct syntax with BoundBlocks it creates when binding constructor with constructor initializer call (two bound blocks are created – outer one defines a closure scope for constructor parameters, the inner one defines a closure scope for variables in the body).
2) Introduce MethodDebugId – a method ordinal and generation ordinal pair
3) Introduce LamdbaDebugInfo and ClosureDebugInfo to represent information (syntax offset) we use to figure out how to map lambdas and closures to the previous generation.
4) Adds a new PDB CDI record (#7) to store lambda and closure debug info.
5) Generalizes CalculateLocalSyntaxOffset to handle positions in field/property initializers and constructor initializers. Use it to calculate syntax offsets of lambdas and closure scopes. (TODO: rename CalculateLocalSyntaxOffset to CalculateSyntaxOffset).
6) Replace lambda and scope ordinal dispenser integers with array builders that collect LambdaDebugInfo and ClosureDebugInfo.
7) Use TryGet- pattern for all VariableSlotAllocator APIs.
8) Implements mapping of lambda method and display class names to previous generation via VariableSlotAllocator.
 (changeset 1407240)

The compiler emits catch-all handler to all async methods. In case of async void methods we also emit the offset of the catch handler to PDB, so that the debugger can pretend that exceptions thrown by the async method are unhandled. Otherwise they are lost. Currently the compiler emits wrong offset, so the debugger is completely confused and displays "no source location" when such exception occurs.

     The fix is to remove a synthesized "nop" instruction that was incorrectly used to track the catch handler IL offset. Instead mark the synthesized BoundCatchHandler node by a flag and create the IL marker in the CodeGen when emitting instructions for such bound node.

     Affects both C# and VB.

     Fixes bug 1114809. (changeset 1405564)

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 TypeCompilationState. 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.
     - 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.
     - Delegate relaxation stubs and their closures have a separate numbering and are distinguished from regular lambdas/closures, since they are immutable and EnC doesn't need to map them across generations.
     - Late-bound AddressOf operator oddly creates real closure and is thus not considered a delegate relaxation for the purposes of synthesized naming.
     - Properties generated to override inherited WithEvent properties are assigned ids in the source order of Handles clauses.

     In order to guarantee uniqueness of the names added during EnC include generation ordinal in synthesized names  wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation. (changeset 1395267)

Currently we include a method ordinal to the name of a synthesized member produced during lowering of the method. When a method is added during EnC in the middle of existing members the ordinal is not enough to avoid name conflicts with the previously emitted synthesized members.
     In order to guarantee uniqueness of the names we now include generation ordinal in synthesized names as well, wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation.

     An alternative would be to find the highest existing ordinal and start indexing EnC members from there. Such approach would probably work but including the generation number is much simpler and imposes less constraints on the EnC compilation.

     In addition to including the generic ordinal this changeset also fixes a couple of bugs that were previously masked or we haven't had coverage of the scenarios:
     - the EnC changeset calculation was not properly handling additions of synthesized members into existing synthesized classes.
     - SymbolMatcher didn't map local variable types forward correctly for variables of synthesized types.
     - SymbolMatcher didn't handle generic static lambda display classes with generic. Currently we create generic parameters for these classes via alpha renaming of the type parameters of the top-level generic method. VB is constructing fresh generic parameters, which seems a better approach. I'll leave changing this to a follow-up changeset.

     As a byproduct of this change we can now enable editing of methods containing dynamic operations. It just works now! Each update of such method creates a new set of dynamic sites. We don't attempt to reuse existing sites. It's little bit wasteful but it also avoids the need of invalidating the call-site caches. (changeset 1393184)

Static lambdas in generic methods are emitted on per-method display class. Include method ordinal into its name to make it unique.

     The previous change to synthesized name numbering introduced a regression - if two generic methods of the same arity contained static lambdas the resulting assembly had duplicate type names. This change addresses that case.
 (changeset 1391470)