Filter IInteractiveWindowCommands on import...

We need to distinguish commands we want to import in the C#/VB Repl from
those exported by other Repls using the same InteractiveWindow component
(i.e. Python Tools).  Otherwise, commands with duplicate names may be
imported (causing an Exception when initializing the InteractiveWindow).

Unfortunately, there was previously no *good* way to distinguish the
"core" commands exported by the InteractiveWindow (clear, help, reset) and
many of the commands exported by Python Tools (some have an attribute, but
others do not).

This change adds [ContentType("code")] to all the commands that the C#/VB
Repl wants to import.

In as subsequent change, we will cease to export #load as a Repl command
and instead implement it as a language directive (so it will not conflict
with $load in Python).

Notes:
- Changes rev Microsoft.VisualStudio.InteractiveWindow to 1.1.0.0 and add
  a binding redirect for VS
- Changes include minor cleanup of the "core" command implementations

Fix crash in code model where we were blindly casting to an interface.

Ensure ProcessedFieldOrPropertyInitializers.Empty is immutable

Fixes #4003

Remove RoslynLight

Update the CopyCoreClrRuntime script to use project.json

Now that Visual Studio 2015 has RTM'd there is no longer a need to have
RoslynLight.  Customers can use Roslyn.sln now.

Update Using Additional Files.md

Updating readme for VS 2015 release

Update Completion List API to make it easier to provide custom CompletionItem behavior

Disable failing test

The value of nil heap handles in EnC deltas should be zero

Make TokenOfStringCached  independent of length

Incorporate PR feedback from #3813

For lengths that are not between 2 and 16 (inclusive) it immediately
returned its second argument.  For all other cases, it inspected the
string.  When the second argument was anything other than
SyntaxKind.Identifier (in particular, SyntaxKind.XmlNameToken), the
two values would not agree and so the output depended on the length
of the first (string) argument.

For example, passing ("a", SyntaxKind.XmlNameToken) used to return
SyntaxKind.XmlNameToken, but passing ("aa", SyntaxKind.XmlNameToken)
used to return SyntaxKind.IdentifierToken.  Now they both return
SyntaxKind.XmlNameToken.

The only impact seems to be on parsing error recovery.  If this
turns out to make the behavior less desirable, then then we should
change the behavior so that *both* return SyntaxKind.IdentifierToken.

Move non-hosting script tests to the compiler

Update to portable proprietary resources

Return Task from Interactive submissions; change Script.Run to RunAsync

Fix debugger visualizer

A large change again, mostly mechanical. There's a fair amount to clean up and that will come in the next commit.