Dependabot updates not finding official docker image versions when private docker registry is used

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Package ecosystem

Docker

### Package manager version

_No response_

### Language version

_No response_

### Manifest location and content before the Dependabot update

/Dockerfile
```
FROM docker.artifactory.internal.example/alpine:3.14.2
```

### dependabot.yml content

version: 2
registries:
artifactory:
type: docker-registry
url: https://docker.artifactory.internal.example
username: example
password: ${{secrets.ARTIFACTORY_KEY}}
updates:
- package-ecosystem: "docker"
directory: "/"
registries: "*"
schedule:
interval: "weekly"

### Updated dependency

_No response_

### What you expected to see, versus what you actually saw

For a basic setup in GHEC where no private docker registry (artifactory) is used, I have a self hosted runner that’s registered for Dependabot (DP) updates and my Dockerfile uses the shorthand reference of the official alpine image:
```
FROM alpine:3.14.2
```

During a DP update run, it detects that the [registry hostname is registry.hub.docker.com](https://github.com/dependabot/dependabot-core/blob/main/docker/lib/dependabot/docker/update_checker.rb#L496-L498) and since the image name [has one word only, it prefixes](https://github.com/dependabot/dependabot-core/blob/main/docker/lib/dependabot/docker/update_checker.rb#L514-L519) library/ in front of the image, i.e. library/alpine. This little bit of magic is to cater for the official docker image such as alpine, amazonlinux, python etc, [(full list here)](https://github.com/docker-library/official-images/tree/master/library), that were referenced in the shorthand form, so that the list of their image tags can be retrieved. DP detected a new image version and raised a PR. All is good.

---

In another environment with self hosted runners for DP, a private docker registry (artifactory) hosts and mirrors docker images. Dockerhub is one of its mirrors. The Dockerfile is configured with the same image and the private registry prefixed with the internal domain:
```
FROM docker.artifactory.internal.example/alpine:3.14.2
```
The DP updates could not find any image tags for the alpine image. It seems as though when DP tries to resolve the dependencies, it goes through the docker.artifactory.internal.example registry to pull the image via its dockerhub mirror. As docker.artifactory.internal.example doesn’t match the [dockerhub domain logic](https://github.com/dependabot/dependabot-core/blob/main/docker/lib/dependabot/docker/update_checker.rb#L496-L498), DP doesn’t prefix the library/ namespace in front of alpine.

When the Dockerfile was updated to `FROM docker.artifactory.internal.example/library/alpine:3.14.2` to include the library prefix, the DP update was able to detect all the image tags.

Is this a known behaviour? What have others done to resolve this? It is quite common for Dockerfiles to reference the official docker images using the shorthand form.

### Native package manager behavior

_No response_

### Images of the diff or a link to the PR, issue, or logs

_No response_

### Smallest manifest that reproduces the issue

_No response_

Start in docker/lib/dependabot/docker/update_checker.rb, especially the registry handling around the referenced lines 496-498 and image-name handling around 514-519. Reproduce the Dockerfile case with a private registry mirror and compare it with the shorthand Docker Hub case; done means official images such as alpine have their tags detected without requiring library/ in the Dockerfile.

Written by the indexing model from the issue text.