Support local filesystem cache

[lbruun]

In reference to Optimize install-scripts in CI runs I suggest to add possibility to use a local filesystem cache.

Here's the background: CI systems normally have a "caching feature" which is really just some folder which is mounted on the filesystem when the job executes. It would be ideal if the .NET install scripts would support such feature in order to avoid constantly fetching the SDK package from the Internet.

Specifically I suggest a new optional parameter:

   --filesystem-cache   <path>
           If specified, the script will check first in this location before going to this Internet to fetch files. 
           By re-using this folder, repeated downloads of the same file can be avoided. 

I'm proposing this not as a way to do offline installs, but as a way to speedup the download-and-install experience. Thus, the script may still go to Internet to download smaller files (e.g. metadata files), but use the cache to avoid repeatedly downloading larger files.

[baronfel]

This could be useful in abstract, but the team likely won't be prioritizing it. One of the prime use cases for this script is the setup-dotnet GitHub Action, and we find that the actual download step for a given SDK is less than 2s per run. Most time is spent extracting the archive (which isn't a simple extract operation because the SDK isn't truly side-by-side installable). On top of that, caches take a while to mount in such systems, and so any gain during download there would likely be spent in setup.

Having said that, I would certainly not be opposed to a contribution that added this. Presumably it would need to check SHAs of the local files against the SHA of the remote file to prevent re-download (using etags? is there a stable resource for the hashes of the SDKs)?