Re-think repo branching strategy

### Describe the Problem

Currently, we have two branches - `main` and `nightly`, which map to `mcr.microsoft.com/dotnet` and `mcr.microsoft.com/dotnet/nightly` respectively today.

- `main` contains the officially released and supported versions of .NET including All LTS, STS, Preview and RC releases.
- `nightly` contains all of the same images, with the addition of the following:
- nightly builds of Preview and RC releases
- .NET Docker infrastructure changes that are intended to release with the next servicing release
- unsupported experimental images that we want to get feedback on (Ubuntu Chiseled, AOT deps & SDK)

The issue is that each month for servicing, we merge changes from nightly into main.

Before a new Preview release, there are usually two versions of .NET in development at the same time. For example, .NET 8.0 RC1 and RC2. We can only choose one to be in nightly at a time. RC1 needs to be stable and tested before we push it to main (stable). This is ultimately more important for customers, so currently we leave stable public versions of previews/RCs in nightly ahead of a Preview release. However, as soon as branding updates happen for RC2, .NET Devs will still want to test new features against the latest nightly builds. We have no way to provide constantly updated, truly "nightly" builds for .NET Devs.

### Describe the Solution

@jander-msft suggested a 3 branch strategy:

- `main` stays the same as it is
- `staging` contains stable public versions of the "next" release, essentially what will be merged into `main` on servicing day. This could even share the same commit history as main to make merging on Patch Tuesdays easier. This includes infrastructure changes.
- `nightly` - there are a few different ideas about how this branch could behave, just throwing some things out there:
- Stay up to date the latest public builds of dotnet/installer (closest to what we have today)
- Forget about coherency and layering and use the very latest builds from the individual dotnet/sdk, dotnet/aspnetcore, dotnet/runtime repos, just for .NET devs
- Include only pre-release versions of .NET, no stable versions

Using this pattern, Infrastructure changes intended for release would probably need dual check-ins to `nightly` and `staging`, essentially front-loading the work of merging nightly to main for servicing releases.

This still leaves one hole in our offering - what do we do about experimental images we want to get feedback on? For example, it would be valuable for customers to be able to test AOT images against the latest stable version of .NET instead of being locked into using the next preview. It could fit into staging, but as soon as Previews are released, customers wouldn't be able to test AOT against stable .NET 9 Preview versions.

### Additional Context

- Somewhat related: https://github.com/dotnet/docker-tools/issues/649