Create and include with each release tarballs containing all Deb/RPM packages required to install it, as an alternative to packages.microsoft.com

See https://github.com/dotnet/docs/issues/16836 for context. Excerpts:

> when apt is down, we need a fall backs to download the .deb file and install it locally.

> It's unfortunately not as simple as "here's a set of URLs, just replace the version number" because we don't update every single package during every single servicing release. E.g. `dotnet-sdk-3.0=3.0.102` depends on `dotnet-targeting-pack-3.0 (>= 3.0.0)`.

> We may also want to consider offering tarball archives of the Debs and RPMs on https://dotnet.microsoft.com/download, because it's hard to find all right RPMs and Debs on https://packages.microsoft.com manually (even while knowing what you're looking for).
>
> We do provide .NET Core as `.tar.gz`, however it takes more effort to switch over to that installation method from Deb/RPM.

> I like the idea of bundling the needed deb/rpm packages to simplify the experience. We could also go as far as including a bash script that drives the installation so that the experience is simply: download, unpack the tar to a directory, run the script.

> IMHO, whatever path the team takes, it needs to be a one liner. Try
>
> ```
> source < (curl -s https://example.com/install-dotnet.sh)
> ```

I'm filing this issue here to track creating these artifacts somehow in the release process. A particular thing to note is that we need to harvest certain installers from earlier releases, for example targeting packs.

/cc @leecow @nakarnam @NikolaMilosavljevic @dleeapho

---

Note for a script impl:

> > So, the instructions would need to list the entire file set and explicit order they are installed.
>
> It's worked fine for me to include all packages in a single install command. I use `apt install ./*.deb` and stuff like that.