Support incompatible_strict_action_env

首先，在启用严格 action 环境的 Bazel 9 中重现 Windows 案例：一个 data 中包含 py_binary 的 sh_binary。阅读 Bazel launcher 的 runfiles 和解释器查找行为，然后将其与直接执行 Python 以及 RunEnvironmentInfo 方案进行比较。当嵌套二进制文件无需继承 PATH 或使用文档中所述的 workaround 即可找到其 Python 解释器时，即视为完成。

As of Bazel 9, --incompatible_strict_action_env=true is the default.

Almost everything works with that set, the one exception is Windows in a particular case. That particular case appears to be when the python program is a data dep of another binary, e.g. an sh_binary with a py_binary in data. What happens is the Bazel launcher can't find the python interpreter in runfiles, so falls back to looking for python.exe on PATH. When strict action env is enabled, the outer PATH isn't inherited, so python.exe can't be found, and thus the launcher fails to execute.

A direct execution of a python program is ok, since the runfiles structure is present enough that the bazel launcher can find the interpreter.

Other than moving away from the Bazel launcher, I don't see a way to solve this. We've wanted to stop using the bazel launcher anyways, so this isn't a big deal, this case just add additional pressure to do so.

Fundamentally, when a binary is running within another binary's runfiles, the logic to find things is a bit more convoluted. We can use RunEnvironmentInfo so that tests auto-inherit PATH, but this only helps tests. binaries-in-binaries or binaries-run-by-actions wouldn't be affected.

There are two workarounds:

• Set --incompatible_strict_action_env=false (restore non-strict env behavior, which includes PATH)
• Set --action_env=PATH (only inherit PATH for actions)