Test infrastructure fails when sharing runtime-deps Dockerfile between .NET major versions

[lbussell]

Runtime-deps Dockerfiles don't always need changes between .NET major versions. It's desirable to share the Dockerfiles between .NET major versions when this happens, in order to reduce duplication.

Today, when we try to share runtime-deps Dockerfiles between .NET 9 and .NET 10, the test infrastructure fails with the following issue (insert your distro of choice - it happens on all of them):

`mcr.microsoft.com/dotnet/nightly/sdk:9.0-bookworm-slim-amd64` could not be found on disk.

Thanks to our GenerateBuildMatrix logic, we build and test these images in a leg that looks like this (in Azure DevOps pipeline yaml):

    10.0-bookworm-runtime-deps:
      legName: linuxamd6410.0-bookworm-runtime-deps
      osType: linux
      architecture: arm
      osVersions: --os-version bookworm-slim
      productVersion: 10.0
      osVariant: bookworm
      imageBuilderPaths: --path src/runtime-deps/9.0/bookworm-slim/amd64 --path src/runtime/10.0/bookworm-slim/amd64 --path src/aspnet/10.0/bookworm-slim/amd64 --path src/sdk/10.0/bookworm-slim/amd64 

The problem comes when we go to test the images. Our test infrastructure doesn't know anything besides that we want to test the Dockerfiles that we provided paths to.

1. Test the runtime-deps Dockerfile src/runtime-deps/9.0/bookworm-slim/amd64
2. Since it's runtime-deps, try to test a self-contained app on it.
3. In order to build a self-contained app for testing, we need an SDK image.
4. Since it's a 9.0 image, try to use the 9.0 SDK.
5. Blow up since the 9.0 SDK wasn't built in this build leg.

Previously, this worked by using the runtime test class to run a test consisting of a self-contained publish scenario targeting the runtime-deps image. So, in the context of the runtime image, we never would have run into this issue. e.g. we would start with the 10.0 runtime image, then pull the 10.0 runtime-deps and SDK images for the self-contained test.

What we have today is more accurate as because it allows tests for runtime-deps-specific image variants (like some extra images). However, it is highlighting this other issue in our test infrastructure.

The short-term workaround for this is to not share Dockerfiles between major .NET versions. The long-term solution is to implement Use manifest.json to determine which tests to run. (#5337).