#r nuget performance can be improved by caching the paths to the resolved assemblies.

Currently, when #r nuget is run, a temporary project is generated and dotnet restore is run against it using custom targets that emit the paths to the assemblies, which are then passed to FSI using #r /path/to/the.dll. This process does the following:

Currently, when a #r nuget is run, the following steps happen:

1. A .fsproj file is generated in a temp folder. Custom targets are included that will write the resolved assembly paths to stdout.
2. dotnet restore is run on the generated project file (allowing FSI to externalize calculation of the dependency graph.)
3. Packages are downloaded and extracted from the available NuGet sources.
4. DependencyManager returns the list of paths to the assemblies
5. Assembly paths are submitted to FSI using #r

Steps 1-4 include a number of performance-intensive operations, including starting a process, running dotnet restore, and downloading and extracting packages, but all of this can be avoided on subsequent requests for a given combination of packages at specific versions by caching of the assembly paths.

The proposal is to cache the outcome of steps 1-4 using a hash of the .fsproj contents and if this cache exists, proceed directly to step 5. This should shave several seconds off of all subsequent #r nuget invocations for a given package. Any change to the contents of the .fsproj will result in a different cache hash. This includes changes in the implementation details of the temporary project file's contents.

@KevinRansom