Rethink distribution mechanisms for known public releases

This tool has two primary usage modes:

* acquire binaries for one of the publically-available releases
* acquire binaries for a very specific version (e.g. nightlies) from a customizable location

For both cases we construct a URL with a particular layout based on the request parameters, and this URL redirects to a location with the binaries to download. The location we've stored these binaries has a few known issues, specifically for users with certain network configurations.

I propose that for the first use case, "download the latest 8.0 SDK for the Linux platform, x64 architecture", we should download the binaries from the [.NET Release Manifest](https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json) that the release team publishes for each monthly release.

These manifests support
* detecting support status of a 'channel' - for example in the following JSON we can see that the 8.0 channel is currently considered in 'active' status, and that it is an `lts` release:

```json
{
"channel-version": "8.0",
"latest-release": "8.0.4",
"latest-release-date": "2024-04-09",
"security": true,
"latest-runtime": "8.0.4",
"latest-sdk": "8.0.204",
"product": ".NET",
"release-type" : "lts",
"support-phase": "active",
"eol-date": "2026-11-10",
"releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/releases.json"
}
```

* discovering the latest release for a channel - for example in the above JSON the `releases.json` property provides a URL that links to the releases for that version. If we follow that URL, we get another manifest full of entries like this:


Here we can see clearly that we can find the list of assets by filtering on the desired .NET RID. Once we have that release we can easily get
* a download url that uses centralized download.visualstudio.microsoft.com links, which are more battle-tested
* a hash that we can use to validate the download is correct

We should only use this file when

* The user hasn't specified a custom `-AzureFeed`
* The user requests an SDK/Runtime/Asp.Net Runtime via the `--channel` and/or `--quality` options
* The LTS/STS channels do not use quality, and should map to the latest 'stable' release of that kind in the release index
* If `--quality` is daily then the release manifest cannot be used and the Azure Feed should be used

Comienza rastreando cómo los scripts de instalación gestionan --channel, --quality y -AzureFeed, y después compara esas rutas con los manifiestos release-index.json y releases.json de los canales descritos en el issue. Se considera terminado cuando se seleccionan los assets de los manifiestos para los canales estables compatibles y se validan las descargas con sus hashes, preservando los feeds de Azure personalizados y el comportamiento de daily-quality.

Escrito por el modelo de indexación a partir del texto del issue.