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).

1. Compile them against Profile7.
   a. Swap out a few APIs (e.g. using GetTypeInfo for reflection).
   b. Introduce an abstraction layer so that we don't have to instantiate
   DkmDataItem (caused a VerificationException).
   c. Include WindowsProxy.winmd as an EmbeddedResource directly, rather
   than through a resx file.
2. Swap the output locations of the ResultProvider projects: Portable goes
to the main output directory and NetFX20 goes to a subdirectory (NetFX20).
3. Include the Portable ResultProvider assemblies in the EE vsix, rather
than the NetFX20 ones.

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

Ignoring references, which are obviously the high-order bit, the old
strategy was to confirm that the methodToken, methodVersion, and smallest
containing scope were the same as the current context.  This had two
problems:

1) C# hoisted locals are not reflected in scopes and so we were not
invalidating the cache when we stepped across scope boundaries in async
and iterator methods.

2) We had to access the PDB in order to check whether the cache was still
valid (to figure out the smallest containing scope).

We propose a new approach: compute the largest span around the current IL
offset in which there are no scope boundaries (including hoisted local
scopes).  Then, when check cache validity by doing a simple span
containment check (plus methodToken and methodVersion, obviously).

Downside 1: We need all scopes in the method, not just the containing
ones.

Downside 2: If you somehow step around a nested scope (e.g. using
breakpoints), the new approach will invalidate the cache, whereas the old
one did not.

This reverts commit b37052d0.

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.

The primary use of DefineConstants should be to append constant values,
not replace them.  Any time a replacement operation is used it prevents
us from establishing defines in our targets and pushing them down to all
affected projects.