More flexibility when parsing docker config.json (or add a warning to docs)

TL;DR: When parsing docker config.json, `rules_oci` should strip off everything after the hostname (or, if not, add a caveat to the documentation).

I spent more time than I'd care to admit tracking down a problem using `oci_pull` with a private Quay repository. The problem turned out to be that my `$HOME/.docker/config.json` file looked like this:

```json
{
"auths": {
"https://quay.io/v2": {
"auth": ""
}
}
}
```

It turned out that the "hostname" was `quay.io/v2` for the purposes of matching which credentials, which of course did not match `quay.io` that was one of the pre-configured patterns. Therefore the credentials were not being passed along and I was getting a 401 error trying to get the token.

My docker config file as shown above was working for `oci_push` in version 1.x at least.

After debugging I ultimately discovered that removing the `/v2` from the Quay URL solved my problem.

```json
{
"auths": {
"https://quay.io": {
"auth": ""
}
}
}
```

I am happy to make a contribution to solve this, and this contribution seems really easy, but I am wanting to ask for guidance first:

- Should I update [`_strip_host`](https://github.com/bazel-contrib/rules_oci/blob/5ff4c792cab77011984ca2fe46d05c5d2f8caa47/oci/private/authn.bzl#L62-L64) to strip off `/v2` too, or `/v\d+`, or anything after a slash?
- Should I update [docs/pull.md](https://github.com/bazel-contrib/rules_oci/blob/5ff4c792cab77011984ca2fe46d05c5d2f8caa47/oci/private/authn.bzl#L62-L64) with a warning about the situation I encountered?
- Should we add a warning to [`_get_auth`](https://github.com/bazel-contrib/rules_oci/blob/5ff4c792cab77011984ca2fe46d05c5d2f8caa47/oci/private/authn.bzl#L229-L232) that credentials were found for `quay.io/v2` but not `quay.io` (in my case), so the user has a hint where to look?

Thanks in advance!

Start with oci/private/authn.bzl, especially _strip_host and _get_auth, and compare the documented Docker config expectations in docs/pull.md. Resolve whether path-bearing registry keys should be normalized, documented, or reported, then verify the chosen behavior against the private Quay example.

Written by the indexing model from the issue text.