We were previously mistaking "<>" as identifier start characters in the debugger.  This prevented you from evaluating open generic types with a single type parameter.

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.

Our EvaluationContext cache invalidation computation was consuming the
method token and version, but not the identity of the declaring assembly.
This lead to a strange bug where we would reuse the cache across assembly
boundaries if consecutive breakpoint happened to have the same method
token (each in its own assembly).

I believe this bug existed before I revised the cache invalidation
computation and we were just getting lucky - we used to check the spans
of all containing scopes, which are unlikely to match exactly across
assemblies.

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.

The expression compiler returns information to the debugger in the form
of .NET assemblies.  These assemblies should not contain embedded
declarations (i.e. "My.*").  At best, these declarations are useless.  At
worst, they hide the declarations in the user's own assembly.

As a bonus, this fixes an issue we were having with being unable to
compile the embedded declarations in cases where two copies of
EditorBrowsableAttribute were loaded (since neither is "closer" or more
accessible while debugging).

Fixes #946.

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.