[Proposal] Consider building and distributing dotnet using official distribution package sources

For now, Microsoft is using it's own 3rdparty repositories, located at `packages.microsoft.com`. While dotnet is an open source project under MIT license, dotnet distributed like a proprietary 3rdparty blob without source code available (from OSS point of view).

And even more, I can't find `.src.rpm` packages on `packages.microsoft.com` repositories, that means the build steps required to produce this rpm package is hidden from us, users. As the source code the package is built from. This raises questions: are those packages actually built from source or they're just a repack of a portable `.tar.gz`? This is not transparent.

The lack of official/semiofficial packages in distribution repositories (in my case, Fedora. But is valid for Debian/Ubuntu too) slows down the spread of .NET on Linux. There's some of pros for integration, I could think of:
* Distribution packages built with target distribution in mind. 3rdparty packages doesn't integrate into the target distribution well. They built to be widely compatible, as I can tell without .spec file available.
* While the package integrated into distribution repositories can be installed with one command, as the SDK for development. 3rdparty packages require additional, unnecessary steps to install/update. There's a need to install 3party repo just to use a runtime and to run .Net application (not self-contained). And for RedHat-based distributions, you can even use rpms to produce containers, this allows dotnet to be used easier in prod (bonus points).
* 3rdparty packages has a slowdown in supporting a new distribution version. Fedora suffers from that mostly, because of update cycle. Packages integrated in Fedora can be built against rawhide as _future_ target and issues with the new distribution version can be corrected even before it becomes _branched_.
* Official distribution packages are transparent to users and allow contribution to the build process on the same level, as GitHub PR's. Just git pull, edit spec/dist, push, pull request.
* Distribution packages are always build and run against latest shared library versions available in distribution. This means security, but in rare cases - a bit of a headache.
* Updates easily handled by distribution package manager. If there's fixes, just rebuild the package. Some distributions allow diff updates for packages, using projects like DRPM.
* Using 3rdparty repos to install OSS without proper reason **not** to integrate it to the distribution (like copyright or weird licensing) is discouraged by community.
* RPM Specs and DEB dists can be used as a perfect reference for build steps required to build package correctly from scratch for Linux. Which is good for other, not directly supported distributions. If you decide to not support ArchLinux/Gentoo, for example, using available spec/dist files they can recreate build process and integrate dotnet on their own.
* Distribution integrated runtime will allow packaging .Net software in that distribution natively, without the need to use [self-contained deployment](https://docs.microsoft.com/ru-ru/dotnet/core/deploying/#publish-self-contained). There's a change what crossplatform dotnet gui/cli applications will appear in the future, native dotnet support in distributions is a huge welcoming gift for developers, even in the containers era. Perfect example: PowerShell, I'm looking at you. For now, even if dotnet supports Linux, it's still considered as a foreign/alien technology, because it lacks integration with Linux on the level of Mono. This slows down it's usage in Linux. (Please, don't be like Java, I'm begging you :pleading_face:!)

TL;DR (main ones): It requires some steps to install, it can be distributed without support for my distribution features (only standard linux features included), the build process is not transparent (what is discouraged by OSS community + contribution is limited), updates coming from single point (hello SPOF) and unable to package an app using dotnet-runtime into the distribution.

As of cons:
* Packages in distributions must be maintainted by someone. By a community member or by developer itself. Yes, it requires some time to be invested, of course.

Or at least, package must be published for review to the distribution and this can be decided later on.
* The RPM spec/DEB dists file(s) published should comply with the target distribution guidelines and should build software from the source code. This includes some degree of pain on the first steps, because **Linux is fragmented**. But it will pay out with time, because spec file/dists are open source. Everyone capable of building rpms/debs could contribute later.

For RPMs, it doesn't necessary to make a new spec file for every distribution in family. There could be one for CentOS/Fedora and one for OpenSUSE/SLES family. With some RPM macro [s]crutches[/s] magic, this could be done for sure.
* In most distributions, bundling 3rdparty libraries is discouraged or forbidden. This must be considered. If the library is OSS, this should not be a problem, but maybe, a little more of a headache/time investment.

Integrating dotnet into distributions is a next big step in Linux support which should be considered.