Update registry paths on Archives page

What does this MR do and why?

Adds handling for a third Archives image endpoint, used for listing archive images on this page: https://new.docs.gitlab.com/archives/.

We have 3 endpoints because we changed our Docker registry path after introducing Lunr search in 15.6, and now we'll have another change when we launch on the gitlab-docs-hugo project.

The template applies logic like this:

1. Fetches responses from all endpoints in order (v3, v2, v1)
2. For each endpoint:
   • Filters for stable versions
   • Sorts versions within that endpoint
   • Adds endpoint information to each version
3. Combines all versions into one list
4. Sorts the combined list
5. Renders versions in order, skipping duplicates. If a version exists in multiple endpoints, uses the first/newest endpoint.

Closes #155 (closed)

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Configure a local GitLab Docs environment: https://gitlab.com/gitlab-org/technical-writing-group/gitlab-docs-hugo/-/blob/main/doc/setup.md.
2. Edit hugo.yaml locally and set the value of hugoLaunchVersion to a recently released version (like 17.5)
3. Run make view and visit the archives page (http://localhost:1313).

Expected behavior:

• You should see the new Hugo project registry path in the Archive list for versions equal to or newer than $hugoLaunchVersion for versions if there's a container image for it (https://gitlab.com/gitlab-org/technical-writing-group/gitlab-docs-hugo/container_registry/8197615)
  • So, right now, 17.7 exists on the v2 endpoint, but not v3, so we use v2 🙃 this will all less weird when we're cutting normal releases and new releases are all from this project.
• Releases should be in order, desc, by semantic version number.
• List should only have links to actual published container registry entries.
• As before, the v1/v2 endpoint is split at 15.6.

Merge request acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this merge request.