Perform R package discovery in a separate process

Add a client and server wrapper around RInterop for package discovery to
prevent VisualStudio from crashing if there are concurrency or other
errors related to accessing R through RDotNet.

Cleanup obsolete commented code.

Hardening stability and recovery of RInteropServer

The RInteropServer was still prone to crashes and was failing to recover
after a crash. These fixes prevent multiple threads from calling the
server at once and avoid an unnecessary R eval that was leading to
crashes under heavy concurrent load.

Add exe files to lookup assembly lookup

The RProvider.Runtime assembly is now an exe, so exe files need to be
included in the assembly resolution for libraries.
Create a new RProvider.Server project for exe

The RProvider.Server.exe will provide a remote proxy to an R session for
package discovery. This way, RProviderRuntime is a library, rather than
an exe, and there is a cleaner separation between the runtime and design
time components of the type provider.
Remove thread locking from RInterop

Thread safety should be the caller's responsibility. The type provider
is thread-safe as it calls through the RProvider.Server proxy which
performs its own locking to guarantee thread-safety.
Revert assembly resolution change

This change was only necessary if we were treating exe files as
libraries.
Split type provider into run-time and design-time

There is now a design-time assembly for RProvider.
Remove comments from build script
Fix for running as a NuGet package

RProvider assembly isn't loaded when the DesignTime assembly is loaded
since it has no real dependencies on it. Also, the DesignTime assembly
needs to make sure that the AssemblyResolver that can find the RDotNet
assemblies is in place first, before anything else is done. This change
ensures that the AssemblyResolver is registered. Further, it places the
Configuration module strictly in the Runtime assembly which is
guaranteed to be loaded by both the RProvider and the DesignTime
assemblies. Always going through the same module ensures we can resolve
that module and retrieve the configuration for that module.
Merge RProvider.Server into RProvider.Runtime

We don't want to have too many assemblies. My original intent had been
to merge RProvider.Runtime into RProvider, but this introduced a
circular dependency through RProvider.DesignTime via the design time
type provider annotation.

This fixes NuGet packaging that wasn't quite right in the previous
commit and has been verified using the build results as a local NuGet
repository.
Separate R runtime from the server executable

We discussed this with @hmansell and this is probably the most reasonable setup.
The original code worked, but had an unfortunate consequence that the generated
code and the type provider referenced an assembly compiled as executable - which
is confusing. So, this splits the R provider into 4 assemblies - I'll add more
documentation in the next commit.
Add developer notes and refactor assembly resolution

This adds a single page to the documentation which explains how
the different parts of the project are structured and why. I also
updated the template (to match with F# Data, Deedle etc.) and updated
to the latest version of the tools.

I did one minor refactoring, which moves the duplicated code to
setup assembly resolution (and I unified the part that look for
already loaded assemblies and the part that searches NuGet folders)
Merge pull request #1 from tpetricek/remote-process

Separate R runtime from the server executable
Merge pull request #82 from dcharbon/feature/remote-process

Perform R package discovery in a separate process
Merge branch 'master' of https://github.com/BlueMountainCapital/FSharpRProvider into rdotnet_1.5.11