We were previously assuming that "this" was always hoisted in async/iterator state machines.  This is not true in optimized code.

(fixes #2406)

Runtime binder calls take a System.Type that they use for things like
accessibility checks.  The expression compiler was incorrectly passing the
result type it synthesized and the regular compiler was incorrectly
passing a nested type in the async lambda case.

Fixes #878

...the same way we expand display classes and state machines.  If we see a
local or parameter with a transparent identifier generated/mangled name,
we should instead include the properties of its (anonymous) type in our
list of bindable symbols.

Points of interest:
1. Transparent identifiers can be chained (i.e. have transparent
identifier properties).
2. Transparent identifiers can be captured (i.e. they might be display
class fields, rather than locals or parameters).
3. Display class instance locals cannot appear within transparent
identifiers (i.e. the recursion goes in only one direction).
4. For the benefit of the debugger, we're actually using fields, rather
than properties.  As a bonus, this was more consistent with the display
class case and, therefore, easier to implement.

TODO: Make a (hopefully) similar change in VB.

Move aliases out of ```EvaluationContext``` so that they don't interfere with our caching strategy.

Clean up the overall diff.

Populate the new DkmClrLocalVariableInfo.FullName property.

Note: FullName is the expression used for Add Watch and will generally be
the local's name, whereas Name is the string displayed in the Locals
window and may be a prose description of the local (i.e. not the local's
name).

1) Instead of asking for the type of an individual alias to determine if
it exists in the current context, ask for a list of all aliases up front.

2) Include aliases in the result of CompileGetLocals (so that the debugger
no longer has to partially populate the window).

Bonus: Fixes #878.

We shouldn't ignore custom debug info for a method just because it doesn't contain import records.  It may still contain info about local variable scopes, dynamic info, etc...

Note:  VB did not have a problem with this scenario, but I added a unit test for good measure.

(fixes #2240)

This is the second of a sequence of changes.  (The first was 3dd1f2bf.)  In
this change we start returning custom type info (effectively just the
flags of DynamicAttribute packed into a byte array) from calls to the
expression compiler so that they can be consumed by the result provider.

TODO: The API for locals is still in flux and we don't presently have a
place to return the custom type info.

TODO: This change does not associate custom type info with locals declared
in the Immediate window.

Since hoisted locals are fields, they are in scope throughout the entire
method body.  However, from the user's perspective, they are still locals,
so we attempt to retain their original scopes during debugging.
Unfortunately, C# and VB use different mechanisms for doing so.  In order
to make the code more consistent, and to simplify consumption of the new
PDB format (which is more similar to C#), we introduce an abstract type
InScopeHoistedLocals that represents the set of in-scope hoisted locals in
a consistent way in both languages (and both PDB formats).

Rebased from https://github.com/tmat/roslyn/tree/DiaSymReader

Been almost a month since the code formatter was run so this change was
a bit larger than would be expected for a normal (weekly) update.  Diffs
mostly around:

- Whitespace changes
- Missing copyright headers
- Missing visibility modifiers

In the dev12 PDB format, usings and imports were encoded as strings in
PDB files.  The strings were structured, but required a certain amount of
guesswork (for example, you might not know whether you were importing a
type or a namespace until after binding).  In the new PDB format, usings
and imports are represented as structured blobs and tokens are used
wherever possible.

This change introduces two new class hierarchies, ImportRecord and
ExternAliasRecord, that the expression compiler can pass around instead
of raw strings.  Unfortunately, there is still switching logic in two
places - both when these types are instantiated and when they are
consumed.  The instantiation switch is very simple - we just check for
the appropriate version of ISymUnmanagedReaderX.  The consumption logic
is more complex, because the new and old representations differ
substantially.

TODO: Presently, there is very little code for consuming the new PDB
format, since the APIs are not yet available.

In the dev12 PDB format, usings and imports were encoded as strings in
PDB files.  The strings were structured, but required a certain amount of
guesswork (for example, you might not know whether you were importing a
type or a namespace until after binding).  In the new PDB format, usings
and imports are represented as structured blobs and tokens are used
wherever possible.

This change introduces two new class hierarchies, ImportRecord and
ExternAliasRecord, that the expression compiler can pass around instead
of raw strings.  Unfortunately, there is still switching logic in two
places - both when these types are instantiated and when they are
consumed.  The instantiation switch is very simple - we just check for
the appropriate version of ISymUnmanagedReaderX.  The consumption logic
is more complex, because the new and old representations differ
substantially.

TODO: Presently, there is very little code for consuming the new PDB
format, since the APIs are not yet available.

This change also ensures that we get non-fatal Watson reports when we're in the continuation of a call to get generic type arguments or argument values from the debugee process.