Remove os.version-spanning indexes

What does this MR do?

Removes os.version-spanning indexes.

Why was this MR needed?

After !5316 (merged) was merged, @shanushpt reported poor behavior with the new image indexes that include multiple os.version components. If we cannot rely upon the Windows docker implementation to choose a proper component, it's prudent to avoid joining them together in a single index.

This MR opts to remove the %-servercore and %-nanoserver image indexes entirely. Instead, we create os.version-specific indexes, %-servercore1809, %-servercore21H2, %-servercore24H2, %-nanoserver1809, %-nanoserver21H2, and %-nanoserver24H2. In addition, I opted to "bless" the 24H2 version to join the cross-OS images, % and %-pwsh.

There are a few decisions to be made before merging this:

1. Of the six indexes created, only two of them (%-servercore24H2, and %-nanoserver24H2) include multiple, architecture-differentiated components. That raises the question of whether it's worthwhile to even include these single-image indexes. Effectively, %-servercore1809 is identical to x86_64-%-servercore1809, for instance. Perhaps there's some small benefit in following the naming convention, but I think it could be easily argued that it only makes sense to add these if the image index contains multiple component images.
2. If we cannot rely upon Windows to choose a proper component based on os.version, do the cross-OS indexes make sense? If a given user on a given version of Windows is using the % tag, and we update the blessed version that's included, and that newly-blessed version is not compatible with their host OS, the tag will stop working for them. Perhaps that just means we can only change the blessed version on new major version releases, but do the release schedules line up sufficiently? I have my doubts. I feel Windows not properly choosing the right os.version makes the cross-OS indexes far less useful.

What's the best way to test this MR?

Similar to !5316 (merged), I validate locally by downloading the artifacts from the binaries job in an existing pipeline, extracting to the root of the project, then pushing manually.

1. helper images: [alpine alpine-pwsh ubuntu ubuntu-pwsh ubi-fips concrete]
2. helper images: [windows-nanoserver-ltsc2019 windows-servercore-ltsc2019]
3. helper images: [windows-nanoserver-ltsc2022 windows-servercore-ltsc2022]
4. helper images: [windows-nanoserver-ltsc2025 windows-servercore-ltsc2025]
5. helper images: [windows-nanoserver-ltsc2025-arm64 windows-servercore-ltsc2025-arm64]

Run the test:

cd scripts/pusher
rm pusher
go test
go build
./pusher -gen-indexes helper-images.json registry.test:8443/sandbox/gitlab-runner/gitlab-runner-helper bleeding

What are the relevant issue numbers?

#39551 brought the issue to my attention.