Provide a transition for switching the target platform to the exec platform?

In https://github.com/bazel-contrib/rules_oci/pull/590 and https://github.com/bazelbuild/rules_rust/issues/2684 we noticed that a common mistake in rulesets is that they use executables provided by toolchains outside the scope of `ctx.actions.run()`. Namely, they get embedded into runfiles directories of binaries and tests.

One approach to work around this issue is to declare "run" toolchains, where you essentially leave `exec_compatible_with` cleared, but set `target_compatible_with` instead. This is what rules_python uses, which it can do because the toolchain is never directly invoked as part of `ctx.actions.run()`. It's only embedded into runfiles directories, so that a subsequent `py_binary()` can run it. In other cases this is impractical, because there is a desire to use tools both within `ctx.actions.run()` AND runfiles directories. In those cases you need to declare all toolchains in twofold, which is highly inconvenient.

In the PRs linked above we managed to prevent the duplication by adding a special transition like this:

```python
def _transition_to_target_impl(settings, attr):
return {
# String conversion is needed to prevent a crash with Bazel 6.x.
"//command_line_option:extra_execution_platforms": [
str(platform)
for platform in settings["//command_line_option:platforms"]
],
}

transition_to_target = transition(
implementation = _transition_to_target_impl,
inputs = ["//command_line_option:platforms"],
outputs = ["//command_line_option:extra_execution_platforms"],
)
```

This can be combined with a helper rule that depends on a toolchain and returns its configuration through one or more providers. By setting the execution platforms to the target platform, the toolchain resolution is performed in such a way that the exec and target platforms are identical.

Considering that we already needed a transition like this in multiple places, would it make sense to provide it as part of rules_platform? Or would it instead be desirable to extend Bazel's Starlark API for supporting more flexible resolution of toolchains? See https://github.com/bazelbuild/bazel/issues/19645.