Improve CLI Tools support on solution level

[matthid]

Now that we have dotnet cli tool support, we could improve that.
This is one possible root to enable CLI Tools on the solution level, possibly conflicting with #2249

• Paket should be able to generate *.deps.json https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.md
• Paket restore could generate "wrapper" scripts with the correct dotnet invocation, for example
  paket-files/.bin/compile-fsc

  #!/bin/bash
  "dotnet" \
      exec \
      --depsfile ~\.nuget\packages\.tools\dotnet-compile-fsc\1.0.0-preview2-020000\netcoreapp1.0\dotnet-compile-fsc.deps.json \
      --additionalprobingpath ~\.nuget\packages \
      ~\.nuget\packages\dotnet-compile-fsc\1.0.0-preview2-020000\lib\netcoreapp1.0\dotnet-compile-fsc.dll \
          $@

  paket-files/.bin/compile-fsc.cmd

  dotnet exec --depsfile C:\Users\<user>\.nuget\packages\.tools\dotnet-compile-fsc\1.0.0-preview2-020000\netcoreapp1.0\dotnet-compile-fsc.deps.json --additionalprobingpath C:\Users\<user>\.nuget\packages  C:\Users\<user>\.nuget\packages\dotnet-compile-fsc\1.0.0-preview2-020000\lib\netcoreapp1.0\dotnet-compile-fsc.dll  %*

• Tell people to add "./paket-files/.bin" to PATH via
  PATH="./paket-files/.bin:$PATH"
  or SET PATH=paket-files\.bin;%PATH%
  -> People can use dotnet tools directly on solution level for example
  compile-fcs --help

Why is this conflicting with #2249? Because we could probably get away with generating project.assets.json as well instead of *.deps.json. But imho we should skip assets.json if possible. That file is owned by nuget while deps.json is owned by the runtime alone.

This would be a first step to simplify dotnet fable yarn-run start into fable yarn-run start.
Question is can we improve that even further to make it work on any folder within the solution folder?

Is this a way forward? What do you think?

/cc @enricosada @forki

[matthid]

Ok I think I have another idea (maybe a bit crazy).

Assume that for every cli tool we generate wrapper scripts in .nugetcache/.clitools
These scripts are version independent and call ".nugetcache/.paket/latest/paket.exe $@"
paket will now invoke* the correct tool in the correct version by finding the current lockfile. We could even have "global" cli tools with this.

the only requirement would be to have ".nugetcache/.clitools" in path. Do you think this could work?
In case of a dotnet core paket version we would have a paket wrapper script in .clitools.

*note we could have another indirection to call the correct paket verion before calling the tool

[enricosada]

related to #2919

as a note, dotnetclitool may expect some env var to be set (like msbuild exe etc) because are needed to inspect the project file in some tools. so wrapper should also mimic that

[matthid]

CLI tools are already obsolete.