permit using repo_provided programs in patch_cmds

### Description of the feature request:

In `patch_cmds` it would be helpful to be able to use a repo-defined program instead of a program from the host system, for reasons of hermeticity. For instance, my repo brings in prebuilt versions of `buildozer` and `buildifier`, and I'd like to be able to use them in `patch_cmds`. I am able to do this freely under `WORKSPACE`, and in my own module extensions under bzlmod, since I can `load()` a symbol that contains a dynamically defined path to wherever Bazel has downloaded the program, but I do not see a way to do it with `patch_cmds` for things like `single_version_override()` or `archive_override()` under bzlmod, since I cannot `load()` in `MODULE.bazel`.

If there were a way to do `$(location)`-style substitution on the `patch_cmds` commands, together with a `data` attribute enumerating the labels to be substituted, that would probably do it.

### Which category does this issue belong to?

External Dependency

### What underlying problem are you trying to solve with this feature?

I want to be able to use a repo-defined buildozer in `patch_cmds` and not have to have buildozer installed on the system.

As I am trying to enable bzlmod, it would be great to avoid needing to turn existing uses of a hermetic buildozer program in `patch_cmds` into patches, since patches are harder to maintain.

### Which operating system are you running Bazel on?

Ubuntu 24.04

### What is the output of `bazel info release`?

release 8.3.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text

```

### Have you found anything relevant by searching the web?

No

### Any other information, logs, or outputs that you want to share?

Slack thread: https://bazelbuild.slack.com/archives/C014RARENH0/p1758115298461909

Start by tracing patch_cmds in single_version_override() and archive_override() under bzlmod, then compare how repo-defined programs are loaded in WORKSPACE and module extensions. Define how $(location)-style substitution and a data attribute would work in MODULE.bazel, including what completion and hermeticity should look like; the issue links a Slack thread for additional context.

Written by the indexing model from the issue text.