Fix unresolved `${out_dir}` token in dep env files (#4124)

### The bug

Since the `OUT_DIR` sanitization work (#4050 / #4011, first released in
0.71.x), `outputs_to_dep_env` redacts the producer's `out_dir` to the
generic `${out_dir}` substitution token, the same way `outputs_to_env`
does.

That redaction is only correct for `_bs.env` files, which are consumed
by the target that directly owns the build script (where
`process_wrapper`'s `--out-dir` resolves the token to the right
directory). Dep env (`DEP_*`) files, however, are consumed by
*downstream* crates' build scripts: their runner only substitutes
`${pwd}`, and their own `out_dir` points to a different directory. The
token is therefore left unresolved, or would resolve to the wrong
directory.

Real-world failure: `libssh2-sys`'s build script fails to find `zlib.h`
because `libz-sys`'s `DEP_Z_INCLUDE` contains a literal `${out_dir}`
path component. Found while upgrading `rules_rust` to 0.71.3 in
dfinity/ic (see dfinity/ic#10632, where this fix is currently carried as
a patch).

### The fix

Only substitute the exec root in dep env files and keep the real
`out_dir` path. That path is valid for consumers: the producer's
`out_dir` is a declared input of downstream build script actions.

### Tests

* Unit test
`out_dir_in_dep_env_value_is_not_redacted_to_substitution_token` in
`cargo/private/cargo_build_script_runner/lib.rs`.
* End-to-end regression test `//cargo/tests/dep_env:build_read_out_dir`
mirroring the libz-sys → libssh2-sys scenario: a producer build script
advertises `cargo:include=$OUT_DIR/include` and the consumer build
script asserts `DEP_Z_INCLUDE` points at an existing directory. Fails
without the fix, passes with it.

---

Assisted-by: GitHub Copilot