[Request]: support credential helpers

### Feature or enhancement request details

Docker and other compatible CLIs support credential helpers, which are separate CLIs to dynamically provide credentials for configured repos.

https://docs.docker.com/reference/cli/docker/login/#credential-helper-protocol

In `~/.docker/config.json` these are configured like so:

```
{
"credHelpers": {
"cgr.dev": "cgr",
"us-east4-docker.pkg.dev": "gcloud",
...
},
```

When configured this way, when `docker pull` needs to get creds for `cgr.dev`, it executes `docker-credential-cgr` (i.e., `docker-credential-`), passing the host on stdin, and parsing the JSON output of the program to receive credentials.

For example:

```
$ echo cgr.dev | docker-credential-cgr get | head -c 60
{"ServerURL":"cgr.dev","Username":"_token","Secret":"eyxxxxx
```

This mechanism lets registry host providers implement their own auth schemes by providing cred helper binaries to produce auth tokens, which are typically short-lived.

It seems that `container pull` etc do not support invoking configured cred helpers in the same way, instead expecting users to run `container login` to store long-lived credentials in the keychain.

This essentially means that, in order for `container pull` to pull from private registries, long-lived credentials are required, and registries that don't prefer long-lived tokens (like `cgr.dev`) are not well supported by `container pull` etc.

Is this something that's on the roadmap? Or if not, is there an explanation for why this should not be supported? The keychain is a trusted place to store long-lived credentials, but short-lived credentials dynamically provided in a standard way should also be supported IMO.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct