DkmClrValue.GetMemberValue also needs a DkmInspectionContext parameter...

EE: Bind to intrinsic methods from assembly supplied by the debugger

These files are a hold over from when Roslyn was in TFS.  They aren't
needed anymore now that we are in git.

closes #858

Fix for #271: Compiler crashes if it cannot locate resources for analyzer

CLR calls us back to search for presence of satellite resource assembly with ".resources" suffix, before attempting to go back to the main assembly as a fallback for resources. However, during this callback we were trying to load the satellite assembly without checking if the file exists on disk, causing an unhandled FileIOException.

Adding the NeutralResourcesLanguageAttribute in PR #831 caused the CLR to directly go to the Main assembly for resources, without making the satellite assembly callback.

I removed this attribute locally from our analyzer assemblies, and with the added File.Exists check, we correctly return null for satellite assembly callbacks and CLR eventually falls back to the Main assembly for resources and we are able to find resources.

Re-enable AsyncLazy tests by rewriting them and improving AsyncLazy's behavior in one or two places.

Move our extra solution to work with CTP6

Filed issue #860 to cover tracking down these failures.

This change moves Roslyn2013.sln to work with Visual Studio 2015 CTP6.
This allows customers, and Jenkins, to build and test significantly more
code than was available with the old solution.

This is still not as full Roslyn.sln because not everything is buildable
against CTP6.  In particular our Visual Studio components and all of
their dependencies can't build due to API changes we depend on that came
into being after CTP6.  It is much closer though than our previous
solution.

As a part of this change I also renamed Roslyn2013.sln to
RoslynLight.sln.  The 2013 moniker was no longer valid and lacking a
better word I chose light (it has less projects and hence is lighter).

When a request to AsyncLazy gets a cancellation, we asynchronously
cancel the underlying Task, since any continuations might run inline
and cause surprises. This meant that if cancellation happened during
a call to GetValueAsync or GetValue where the underlying computation
was synchronously completed, there was a race where the task that
gets returned might or might not be cancelled. It didn't strictly
matter -- since cancellation is best-effort it was fine by the contract.
But to test an earlier bug, we forced it into the non-cancelling
case by simply stopping up the thread pool so the asynchronous
cancellation never happened. That approach was really evil, so we try
something else.

Now, we adjust the tests to assert the slightly stronger statement that
once a computation runs and returns a value, it's cached, even if
the value is not handed out. (The implementation already did this,
but we now assert it.) We also tweak the cancellation handling to
cancel the returned task more aggressively. This avoids the race
between async cancellation and synchronous value returning in the
context of the unit test, so we can assert behavior better. In general
there's no guarantee, but it's now guaranteed "enough" our test can
test the other behaviors well.

make sure we cancel outside of enumeration

Add explicit null checks during module lookup

Improve exception filter parsing error recovery

When we originally introduced exception filters to C#, we used the if
keyword in the filter clause.  To avoid confusion with regular if
statements, we switched to using the when (contextual) keyword.

Unfortunately, the if syntax was around long enough that code with that
syntax was stored in the source server database.  Now, when you try to
debug such files, they parse very badly.  In particular, there is a file
in the debugger in which thousands of lines of text become skipped text
trivia and the resulting syntax tree results in an
InsufficientExcecutionStackException whenever that file is displayed.
This makes it very difficult to inspect older dumps.

A simple solution is to allow the if keyword and replace it with a when
keyword with an error attached.

With this change applied, the debugger crash is resolved.

We got a release-build dump with a NRE in a location that didn't make sense.  Based on our best guess of what happened (something that should be impossible) add some explicit checks so that we'll get a clearer stack trace if it happens again.

No tests since we still believe this is impossible.

Disabling test:  ConditionalMemberAccessRace002

Failing due to #836

This isn't safe when running tests in parallel, so it'll have to go.

Fix for #271: CLR calls us back to search for presence of satellite resource assembly with ".resources" suffix, before attempting to go back to the main assembly as a fallback for resources. However, during this callback we were trying to load the satellite assembly without checking if the file exists on disk, causing an unhandled FileIOException.

Adding the NeutralResourcesLanguageAttribute in PR #831 caused the CLR to directly go to the Main assembly for resources, without making the satellite assembly callback.

I removed this attribute locally from our analyzer assemblies, and with the added File.Exists check, we correctly return null for satellite assembly callbacks and CLR eventually falls back to the Main assembly for resources and we are able to find resources.

Reduce allocations from the ConcurrentDictionaries in TypeSymbol interface implementation maps.

Address couple of issues related to analyzers: 

1) Don't crash command line builds when reporting analyzer diagnostics. Reporting analyzer diagnostics may involve invoking user code for LocalizableString message, which may throw while finding resources or for other unknown reasons. We catch exceptions from these callbacks and report a diagnostic with the inner exception message.
 I verified that this fixes the crash seen in #271 and #813 and we started seeing this new info diagnostic.

2) Workaround for #271: The underlying cause of the crash is that our assembly resolver/CLR is unable to fallback to the main assembly for resources and ends up looking for the satellite resource assembly. We had seen this crash quite a while back, but it went away and this seems to have come up again. Workaround, as applied back then, is to mark the analyzer assembly with NeutralResourcesLanguageAttribute.
 I verified that adding this attribute to our core analyzer assemblies caused the resource to be correctly found and we don't even see the exception diagnostic from (1) above, but instead the actual diagnostic reported by the analyzer.

Disable tests related to GitHub issue #204

Fix #565: Syntax node actions are not called for field declarations in compiler analyzer driver if the declaration defines multiple variables

Simplify logic for execution of syntax node actions for field declarations: If there are multiple decls, execute syntax node actions for entire field decl (and its descendants) when processing symbol declared event for first field within it, and skip syntax node actions for rest of fields defined within that declaration.
 Current logic is unnecessarily complex in that it tries to execute syntax node actions for individual variable declarators when processing corresponding field symbol declared event, and executes the node actions for shared nodes (e.g. defining type syntax node) when processing first field symbol, and caused this bug to sneak through.

Added regression tests for compiler driver (VB and C#) and IDE driver.

Fix #671 to handle broken code case where there are multiple overrides of DiagnosticAnalyzer.SupportedDiagnostics property