Consider releasing new dotnet-runtime-deps RPM/Deb packages outside the .NET Core servicing cycle

[dagood]

Currently, changes to dotnet-runtime-deps-x.y are checked into this repo and into servicing branches in core-setup, then built along with the rest of the product and shipped as part of a .NET [Core] release.

I believe this has the upside of including manual testing of dotnet-runtime-deps along with any other manual testing that's done per release.

However, this significantly restricts how we can support our users:

• In general: we're unable to support new distro versions or correct mistakes in our packages until a servicing release.
• We do try to prepare for new distro versions. However, the distro may change its package names last-minute in its own release cycle, breaking our attempt to prepare. This delays package manager support for .NET on that distro until our next servicing release if we don't/can't catch it in time.
• We don't always prepare correctly for new distro versions in the first place, and when we catch this, we have to wait until the next servicing release. (Please provide packages for Ubuntu 20.04 core#4360)
• Servicing release dates are somewhat nebulous, so it's unclear how long everyone will need to wait for these fixes or use workarounds.

A conservative approach is to continue maintaining dotnet-runtime-deps in this repo, but loosen up and publish an early build of the package to the distro-specific feed on the Microsoft Linux package repository to unblock our users. This package is metadata-only, so that seems very low-risk to me.

/cc @leecow @rbhanda @nakarnam @NikolaMilosavljevic @dleeapho

---

In source-build, this is flipped on its head. The product is built, then packaged. The dependencies are determined during the packaging process automatically, and/or determined by the distro maintainer. This is more manageable.

[NikolaMilosavljevic]

Per triage: We want to start working on this, but it is not specifically tied to 5.0.

[NikolaMilosavljevic]

[Triage] Most of the time we have monthly releases where we can update dependencies. There is a potential for a delay in case we skip a month and distro updates its dependencies very late in the release cycle. We think those scenarios are rare.