"Roslyn" -> "Microsoft" or "Microsoft.CodeAnalysis"

The targets files were previously split into an open version in
Microsoft.CodeAnalysis.Toolset.Open and a closed version in build/. This
unifies the four targets into two new targets, VSL.Settings.targets and
VSL.Imports.targets, and moves all the targets from ..Toolset.Open into
the build/ folder.

These two changes should have been included in
https://github.com/dotnet/roslyn/commit/8c9ed547c5bc6ad5a9842945688da9b2f189ac8c
but,

1. The references didn't match any of the extraneous VSIX names because
they inline variables.
2. OpenSourceDebug.csproj doesn't drop a VSIX in the output folder, so it
was missed by my validation pass.

The net effect is to remove Microsoft.Build.Tasks.Core.dll,
Microsoft.Build.Utilities.Core.dll, and
Microsoft.VisualStudio.Shell.14.0.dll from OpenSourceDebug.vsix.

Mechanically apply <Private>False</Private> to the newly-appeared
references.

This deletes the empty and unused Desktop assemblies from the code base.

This change removes all C# specific references from
MS.CA.Workspaces.CSharp.Desktop.dll.  This demonstrates the pattern by
which we could migrate the language specific MSBuild code into a shared
DLL which has no language specific dependencies.  This pattern will
allow us to delete both MS.CA.W.CSHarpDesktop and
MS.Ca.W.VisualBasic.Desktop.

This removes the majority of references to the deprecated Desktop
assemblies.  The only remaining ones are in the VSIX projects.  They
must remain until we actually delete the assemblies.

This moves the contents of the CSharp and Visual Basic Desktop
Projects to the Portable counterparts.

closes #2587

Move the analyzer assembly loaders out of `CodeAnalysis.Desktop` and
into the individual host projects (csc. csi, vbc, vbi, etc.). This
solves two issues:

1. The loader types can now be made internal.
2. `CodeAnalysis.Desktop` no longer has a dependency on the loader
implementation, and the loaders can be swapped or modified on a per-host
basis as needed.

Remove CodePage1252Encoding and try to use the built-in Encoding. If not available, then fallback to Latin1

Currently we expect that an analyzer's dependencies are located next to
it in the file system, and we do not require that those dependencies be
explicitly passed to the compiler. These requirements are changing. We
will now allow analyzers and their dependencies to be located anywhere,
and this requires that the full set of analyzers and dependencies be
passed in so that we know where to find them.

In order to load analyzers and dependencies under these new
requirements, this commit introduces the SimpleAnalyzerAssemblyLoader.
This type loads assemblies with a simple `Assembly.LoadFrom`, but it
also hooks the `AppDomain.AssemblyResolve` event in order to find and
load items from its list of dependencies.

Csc.exe and vbc.exe have been updated to use this loader instead of
calling directly into `Assembly.LoadFrom`. It is also exposed to the
workspace layer through the IAnalyzerService type.

Upgrades System.Collections.Immutable to 1.1.34-rc and
System.Reflection.Metadata to 1.0.19-rc.

When the user right-clicks on a rule set file in Solution Explorer and
chooses "Set as Active Rule Set", we ask the associated `IVsHierarchy`
for the name of the rule set file and use that to set the
`<CodeAnalysisRuleSet>` property in the project file. However, the name
returned by the `IVsHierarchy` does not include the full path, so this
only works if the rule set is immediately next to the project file.

For linked files this will generally not be the case. Instead, we need
to ask for the *canonical* name, which will give us the full path. We
then compute the relative path to that file from the project's
directory, and use that for the `<CodeAnalysisRuleSet>` property.

Fixes #1579.

This function relied on CultureInfo which is not a supported CoreFx API.
Moved it out to the Desktop layers where it was actually used.

Binary serialization is not supported in CoreCLR and hence must be removed
from the subset which runs there.  This code is only used to support
CodeLens so rather than moving it around we are simply removing it
completely.  It will be relocated to CodeLens internally to continue supporting
their scenarios.

The Public API changes to DocumentId and ProjectId were necessary to
continue supporting serialization outside of the Roslyn code base.

closes #915

The loading of analyzer DLLS is now controlled by the compiler host.  It
is a behavior the host is forced to provide via the abstract member
CommonCompiler.AnalyzerLoadFunc.

This reverts commit b37052d0.

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.

SourceText now includes the logic to decode efficiently from streams, throwing if binary files are detected and using LargeEncodedText to avoid the large object heap.
EncodedStringText, a shell of its former self, provides the 'desktop' entry point to detect FileStream and decode MemoryStream as byte arrays.

This change moves the contents of VisualStudioSetup into the open,
merging with (and consuming) VisualStudioComponents. The Components/
Setup split originally existed as a way to allow multiple Roslyn-using
components to have a single source of truth of the MEF exports. This
meant you could have either the interactive window, language services,
or both installed and everything worked. This was important when we
were atop Visual Studio 2013, but now that we're integrated it's buying
us nothing.

The VSIX ID from VisualStudioComponents is preserved so that way any
extensions that declared a dependency on it will still work.

1. Reduce allocations when reading from FileStream.
2. Pre-compute checksum if possible.
3. Reduce allocations for lazily computed checksums.
4. Avoid LOH allocations for large source text.
5. Update EditorTextFactory to optimize for reads from temporary storage

Perf results for the Picasso rebuild scenario:
184 MB total allocations saved. Including: 78 MB of char[], 73 MB of Byte[], 9 MB of string. Also, 35 MB of LOH allocations were eliminated.
 (changeset 1412085)

also, made ITextFactoryService internal (changeset 1406337)

Background:

As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

The coding style transition is automated using a Roslyn based rewrite tool:

https://github.com/dotnet/codeformatter

This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1403394)

Update Microsoft.Net.ToolsetCompilers and Microsoft.Net.RoslynDiagnostics to version 1.0.0-rc1-20150116-01.

Also turn on the DeclarePublicAPI analyzer for all of the C# assemblies that end up in our NuGet packages. I can't turn the DeclarePublicAPI analyzer on for our VB projects yet due to bugs in the analyzer driver. (changeset 1400249)