Fixes #4105.

Make InteractiveWindow states explicit

Suppress 4.6 warnings in CoreCLR projects

Since the warning is in BuildClient.cs which is linked to desktop
projects which don't yet target 4.6, suppress the warning for now

Implements BlobBuilder

Wrap all members that can only be accessed on the UI thread in an inner
class.  (Unfortunately, a struct was too complicated because capturing
```this``` resulted in copying that hid side effects.)

Remove all asserts about running on the UI thread.  Now that all accesses
are funnelled through a single field (and there are only a dozen!), it's
easy to verify by inspection that it is only accessed on the UI thread.

Add unit tests for both the origin bug and for further exploring the
threading behavior of the type (added a bunch of marshalling in response
to exceptions encountered while testing).

Eliminated some dead code.

e.g. Use expression-bodied properties for brevity and explicit interface
implementation to make it clearer which methods are API members.

Instead of having a collection of boolean flags, introduce a State enum
that captures all of the possible states of the window and document
transitions between them.  Furthermore, assert that state transitions only
happen on the UI thread (for synchronization purposes).

Fixes #3970

TODO: The transitions to and from the ReadingStandardInput state are not
well understood/handled (#3984).

Add CoreCLR projects to the Roslyn solutions

Update the DNX build tools, which fixes #3876. Now that the
bug is resolved, add the CoreCLR projects directly to the
compiler solutions.

Check DkmClrAppDomain.IsUnloaded...

Delete unused files

Test for structs in using in async method

Update failing FieldInitializerBindingTests unit test

Telemetry indicates that we're getting an ObjectDisposedException when calling module.AppDomain.Id.  When we enumerate all the modules in the DkmClrRuntimeInstance, we shouldn't be considering modules that were loaded in AppDomains that have been unloaded.

This issue was reported through the following stackoverflow post:

>
http://stackoverflow.com/questions/29230626/why-is-enumerator-movenext-not-working-as-i-expect-it-when-used-with-using-and-a

The Roslyn compiler fixed a bug present in the native compiler around
the use of structs inside a using inside an async method.  The native
compiler was generating some of the method calls on a copy of the struct
which caused  the mutation to be ignored.   Roslyn correctly generates
them all on the lifted value.

Looking around I couldn't find a specific regression test for this
functionality so adding one.

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