[WIP] Spec for image use

The following is the start of a spec for how `dotnet-buildtools-prereqs-docker` images should be used. The intent is that there are a set of approved patterns with the expectation that teams ask for help when the patterns do not work, not that they adopt (seemingly) expedient DIY solutions.

This spec will evolve over time and move to a new location. Solution to https://github.com/dotnet/dotnet-buildtools-prereqs-docker/issues/990.

## Native build

Azure Linux images are provided for native build. These are designed for dotnet/runtime, but may have utility for other repos. If you don't have any C or C++ code to build, don't use these images. They are also used for VMR builds, since those include runtime code.

These images all have `cross` in the name because we [cross build for all scenarios](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md#docker-images), including x64.

Example images:

- `mcr.microsoft.com/dotnet-buildtools/prereqs:azure-linux-3.0-cross-amd64`
- `mcr.microsoft.com/dotnet-buildtools/prereqs:azure-linux-3.0-cross-arm64-alpine`

## Managed build

- Should build on Windows
- Use official source-build templates to validate that source-build leg runs

Source build image:

- `mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream9`

## Testing (in helix)

Current Helix images are enormous, for no obvious reason. We should define new images with very minimal components installed (including Python). We should create new Helix images as new distro versions are releases, such as Azure Linux 3.0, Ubuntu 24.04, and Alpine 3.20. We can decide if we want to backport the changes to older versions.