[codex] Split build-script feature resolution

[dzbarsky]

Cargo resolver v2 keeps normal-dependency features separate from build-dependency features, but rules_rs previously resolved both dependency kinds into one external rust_crate target. This change resolves target dependencies without build dependencies, seeds a second resolution over SUPPORTED_EXEC_TRIPLES, and generates either one target when both resolutions match or _target and _exec targets selected by @rules_rust//cargo/settings:use_exec_features_enabled when they differ. It pins rules_rust commit 7837073014b566291368027aa116cd03fe108049, which composes the build-script exec transition with the marker transition through config.exec().and_then(...).

The build_exec_feature_split fixture requires target_feature from a normal dependency and exec_feature from the same crate as a build dependency. The shared crate fails compilation if both features are enabled, so the fixture verifies that the target library and build script receive different feature sets.

Validation used source-built Bazel commit 0878dd724149b73a731ab83859a55a65e9b438ed: @build_exec_feature_split//:_workspace_deps passed with 1,720 actions, //rs/private:all passed 28/28 tests, cargo check --locked passed for the fixture, and Buildifier plus git diff --check passed.

Current scope: proc macros are unchanged, and seed_exec_build_dependencies unions features from all active target triples before resolving each exec triple. Exact target-specific build-script features require resolution keyed by both target triple and exec triple.

[pawelchcki]

I’m hitting what looks like relvant issue while building ESP32-C6 firmware with rules_rs 0.0.102.

platform_triples = [
    "riscv32imac-unknown-none-elf",
    "x86_64-unknown-linux-gnu",
]

portable-atomic is compiled as a host tool with a target-only feature:

--target=x86_64-unknown-linux-gnu
--cfg feature="unsafe-assume-single-core"

This fails because unsafe-assume-single-core is unsupported on x86_64.

FYI I also see leakage in the other direction: log is compiled for bare-metal RISC-V with feature="std", despite the applicable dependency disabling default features.

[dzbarsky]

@pawelchcki does this PR fix the issue for you? It feels like the real problem may be crates enabling features in their deps unconditionally instead of conditioning on cfg-target - but hopefully this helps. We can land it if it does just need to rebase and add a regression test, etc. let me know!