Resolve RDotNet and plugin assemblies when installed via NuGet 

Most of the work is done in [this checkin](https://github.com/tpetricek/FSharp.RProvider/commit/57ce49d1ab3c43103baa55386f5c0fa357687c71). Here is the comment:

> When RProvider is installed via NuGet, the RDotNet library will be located in "../../RDotNet-1.5.5/lib/net40" and when Visual Studio loads RProvider.dll, it fails to resolve this dependency. Previously, we tried to copy the dependencies to the right place with PowerShell script, but this 1) does not work on Mono, 2) does not work with RestorePackages, 3) sometimes does not work for other random reasons. Similar difficulties are with plugins - e.g. Deedle plugin will also be in a separate directory.
>
> This checkin modifies RProvider, so that it can work with NuGet. We setup the AssemblyResolve event handler in the static constructor of RProvider and we let the user configure resolution via RProvider.dll.config. The NuGet package includes a default config that makes things work. To make this work, the "RProvider" type that sets up the AssemblyResolve handler needs to be loaded *before* any type that references RDotNet. This did not quite work - e.g. `CharacterInterceptor` type inherits
from a type in RDotNet and if it gets loaded first, we are too late. So, this also splits the project into `RProvider.dll` and `RProvider.Runtime.dll`. The first one has the provider (and configures AssemblyResolve), but it does not reference RDotNet directly, which makes the whole thing work.
>
> The interfaces implemented by plugins are now in `RProvider.Runtime.dll`, so plugins need to be updated. I did this for Deedle and it works fine.

Aside from that, this also merges concurrency fixes from @dcharbon (#80). I had a couple of Visual Studio crashes after doing the changes above and the locking resolved that. Another minor checkin also adds some Mono/Mac support and minimal Travis integration (to close #70).