Create combo packages

Part of the problem underlying stuff like #347 is the need for this "loading logic" in TorchSharp at all, it's a mess especially the cases for F# Interactive.

On talking it through with @gbaydin, one suggestion was that we should add "runtime ready" combo packages that combine TorchSharp with the appropriate runtime, and also have these ensure that on package restore the native binaries are put together in a place loadable by F# Interactive and .NET Interactive, without any hassle or initialization code.

These would be the three combo packages:

* TorchSharp-cpu
* references matching TorchSharp package
* references matching libtorch-cpu package
* on restore, ensures that native binaries are all available in one known directory

* TorchSharp-cuda-11.1-linux-x64
* references matching TorchSharp package
* references matching matching libtorch-cuda-11.1-linux-x64 package
* on restore, ensures that native binaries are all available in one known directory

* TorchSharp-cuda-11.1-windows-x64
* references matching TorchSharp package
* references matching libtorch-cuda-11.1-windows package
* on restore, ensures that native binaries are all available in one known directory

The above are in addition to the existing packages:

* TorchSharp
* contains managed component
* contains one native component

* libtorch-cpu

* libtorch-cuda-11.1-linux-x64
* plus various "fragment" packages for delivery
* on restore, restitches fragments

* libtorch-cuda-11.1-windows-x64
* plus various "fragment" packages for delivery
* on restore, restitches fragments

It's important to still have the plain "TorchSharp" package because this is what things like DiffSharp.Backend.Torch reference - it's the programming model with (most) of its implementation, but short of the selected libtorch native binaries.