Setup routing for virtual registry maven upstream

What does this MR do and why?

Adds the show & edit routes, controller actions and view templates.

Both the routes are setup as shallow: true so that

1. they look like:
   • /virtual_registries/maven/upstreams/1123 instead of /virtual_registries/maven/2323/upstreams/1123
   • /virtual_registries/maven/upstreams/1123/edit instead of /virtual_registries/maven/2323/upstreams/1123/edit
2. The upstream can be looked up directly by upstream id without the virtual registry id

In both cases, we look up the maven upstream from the database & return it if it belongs to the group

EE: true

This MR does implement the frontend changes required to implement the below designs. These will be part of subsequent MRs

References

Designs for reference:

1. #493842[Edit-upstream.png]
2. #493842[Cache-entries.png]

Screenshots or screen recordings

Upstream edit page	Upstream show page

How to set up and validate locally

Feature.enable(:virtual_registry_maven)
Feature.enable(:ui_for_virtual_registries)
g = Group.find(1) // must be a root group
# create an upstream
u = VirtualRegistries::Packages::Maven::Upstream.create!(group: g, url: 'http://local.test/maven/')

# create a registry_upstream join table row
VirtualRegistries::Packages::Maven::RegistryUpstream.create!(group: g, registry: r, upstream: u)

Visiting following URLs should render the page above

1. http://gdk.test:3000/groups/gitlab-org/-/virtual_registries/maven/upstreams/
2. http://gdk.test:3000/groups/gitlab-org/-/virtual_registries/maven/upstreams//edit

Visiting the above URLs with following tweaks should return 404

1. Using non-existent upstream_id
2. Using upstream_id belonging to another group

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #525927 (closed)