This change drops support for .NET 4.5 and retargets to desktop
4.6 + CoreCLR. It also fixes up various analyzer warnings that
were created due to the move.

Fixes #12926

This reverts commit 720f5c5e, reversing
changes made to 6a6043c3.

also, some bug fixes on bit array I found whle using it in object writer/reader

changes include
make SourceText::GetChecksum and AnalyzerTelemetry contructor public.

added MustRunInProc in IBuiltInAnalyzer and some clean up around serializing Solution/Project/DocumentId and how DocumentState is exposed.

simplified temporary storage service's temporary storage management and added ability to attach to existing temporary storage

solution checksum and serialization service.

added remote host client
- this gives an ability for host (vs) to talk to remote host (service hub)

rename and moving files between feature/workspace layers
- only real change is having ICompilerDiagnosticAnalyzer interface which can either have inproc implementation or out of proc implementation.
- inproc is needed since diagnostics are in feature layer and one who uses feature layer out side of VS host need an implementation.

added RemoteWorkspace
- RemoteWorkspace has host agnostic implementation of roslyn features/services/workspace that will run in remote host

added service hub component and setup project for service hub
- service hub component is basically thin layer that deals with converting data to pass in to RemoteWorkspace

made devdiv insertion tool to ignore servicehub related files

support byte and char array natively in ObjectReader/Writer

These were accidentally changed to UTF-16LE during a recent scripted change.  This went unnoticed because the encoding change didn't register in CodeFlow (indeed if you view a shelve of this change in CodeFlow it will report no changes).  UTF-16 does not work well with Git as it is often interpreted as a binary file.  Moving back to UTF-8 so our GitHub experience works well for customers.

closes #66 (changeset 1403787)

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)

***NO_CI***
 (changeset 1392938)

Splits Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.VisualBasic into portable and desktop assemblies.

Existing Core\Source, CSharp\Source and VisualBasic\Source directories are renamed to Core\Portable, CSharp\Portable and VisualBasic\Portable.
New sibling Desktop folders are added and non-portable source is moved there.
"System.Runtime" references has to be removed in order for the portable project system magic to automatically add facade references.
 (changeset 1281686)

The current implementation of MultiByteEncoding is not portable. This change replaces it with a simpler string serialization technique.

The problem is with GetBytes(char*, int, byte*, int) -- we needed to override this method in order to avoid buffer allocation. But the base method is currently not exposed in portable profile.
We don't actually need to define an ecnoding to serialize strings. We can serialize strings to byte array manually and then write the bytes direaction to the strream.

Taking it one step furtehr we can also avoid using a custom string serialization format as well. Instead we chack if the string being serialized is UTF8-encodable. We already have a helper in MetadataHelpers that answers that question. If it is we use UTF8 encoding, otherwise we use UTF16 encoding. Invalid Unicode characters are rare so we don't need to optimize the latter. (changeset 1267243)