[Bug]: `register_coreutils_toolchains`'s `version` attribute is fixed to a single value

### What happened?

We maintain some regrettable dev machines running CentOS 7, which are running with older glibc versions incompatible with newer coreutils releases. This is causing a bit of grief updating to bazel-lib 2.x, and as a workaround I attempted to downgrade coreutils via
```
register_coreutils_toolchains(
version = "0.0.16",
)
```
however, this fails with
```
ERROR: /home/jacob/foursquare.web/WORKSPACE:39:30: //external:coreutils_darwin_amd64: invalid value in 'version' attribute: has to be one of '0.0.23' instead of '0.0.16'
ERROR: /home/jacob/foursquare.web/WORKSPACE:39:30: //external:coreutils_darwin_arm64: invalid value in 'version' attribute: has to be one of '0.0.23' instead of '0.0.16'
ERROR: /home/jacob/foursquare.web/WORKSPACE:39:30: //external:coreutils_linux_amd64: invalid value in 'version' attribute: has to be one of '0.0.23' instead of '0.0.16'
ERROR: /home/jacob/foursquare.web/WORKSPACE:39:30: //external:coreutils_linux_arm64: invalid value in 'version' attribute: has to be one of '0.0.23' instead of '0.0.16'
ERROR: /home/jacob/foursquare.web/WORKSPACE:39:30: //external:coreutils_windows_amd64: invalid value in 'version' attribute: has to be one of '0.0.23' instead of '0.0.16'
```

Expected behavior: the `version` attribute is respected and the toolchain is bootstrapped using the specified coreutils release.

### Version

Development (host) and target OS/architectures:
in this case, `CentOS Linux release 7.9.2009` targeting linux/amd64, though same issue elsewhere

Output of `bazel --version`:
```
bazel 6.4.0
```

Version of the Aspect rules, or other relevant rules from your
`WORKSPACE` or `MODULE.bazel` file:
2.0.1

Language(s) and/or frameworks involved:
coreutils

### How to reproduce

```shell
1. configure the coreutils toolchain as part of bazel-lib setup (code snippet from `WORKSPACE`):

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
name = "aspect_bazel_lib",
sha256 = "4b32cf6feab38b887941db022020eea5a49b848e11e3d6d4d18433594951717a",
strip_prefix = "bazel-lib-2.0.1",
url = "https://github.com/aspect-build/bazel-lib/releases/download/v2.0.1/bazel-lib-v2.0.1.tar.gz",
)

load("@aspect_bazel_lib//lib:repositories.bzl", "register_coreutils_toolchains")

register_coreutils_toolchains(
version = "0.0.16",
)
```
2. Run `bazel build --nobuild` or similar

### Any other information?

Digging around a bit, this appears to be caused by the underlying `coreutils_platform_repo` repository rule restricting its [version attribute](https://github.com/aspect-build/bazel-lib/blob/v2.0.1/lib/private/coreutils_toolchain.bzl#L201) values to the keys in the [COREUTILS_VERSIONS](https://github.com/aspect-build/bazel-lib/blob/v2.0.1/lib/private/coreutils_toolchain.bzl#L43) mapping, which only contains the latest version.

Not sure what the most reasonable approach for a fix would be... it would be awesome if bazel-lib's `COREUTILS_VERSIONS` mapping could just contain artifact mappings for every version, but I assume that would also entail some maintenance burden to mirror those artifacts and keep the list up to date + add new architectures and whatnot. I have seen other rulesets allow the user to provide their own artifact mapping which is still kind of awkward to use but at least provides an off ramp (e.g. it is not well documented or encouraged, but [rules_scala](https://github.com/bazelbuild/rules_scala/blob/v6.2.1/scala/private/macros/scala_repositories.bzl#L158) does this).

If nothing else, adding back the 0.0.16 version mapping from the [1.39.0 release](https://github.com/aspect-build/bazel-lib/blob/v1.39.0/lib/private/coreutils_toolchain.bzl#L43) as an addition to the current mapping would solve my own personal issues 😄 happy to take a stab at a PR for that if it seems a reasonable band aid.

Start in lib/private/coreutils_toolchain.bzl, especially the COREUTILS_VERSIONS mapping and the coreutils_platform_repo version attribute mentioned in the issue. Reproduce the failure with the provided WORKSPACE configuration and bazel build --nobuild. Done means a supported older version such as 0.0.16 is accepted and the toolchain bootstraps using that release.

Written by the indexing model from the issue text.