support overriding a crate's opt level per compilation mode

Cargo's canonical fast-dev-build recipe optimizes chosen packages while the rest of the workspace keeps opt-level 0 (`[profile.dev.package.""] opt-level = 1`). rules_rust has no equivalent: `rust_toolchain.opt_level` applies to every crate in a compilation mode, and the only per-crate escape hatch is raw `-C` flags in `rustc_flags`, which bypasses the compilation-mode model — one `rustc_flags` value applies in every mode, so a fastbuild override leaks into `-c opt` builds too.

Proposal: an `opt_level` attr on the `rust_*` rules, keyed by compilation mode, substituting the toolchain's opt level for that crate:

```python
rust_library(
name = "hot_crate",
...
opt_level = {"fastbuild": "1"},
)
```

Modes not listed, and crates without the attr, behave exactly as today.

Data point from our monorepo: a profile of a CPU-bound e2e suite put ~55% of CPU self-time in a handful of rarely-edited foundation crates; pinning those to opt-level 1 under fastbuild cut the heaviest test from 158s to ~85s while leaving every other crate's compile time untouched. We carry this as a ~25-line patch (attr in `rust.bzl`, one substitution in `construct_arguments`) and can send a PR if the shape is acceptable.

Start in rust.bzl to trace the rust_* rule attributes, then follow construct_arguments where the toolchain opt level is substituted. Add the compilation-mode-keyed opt_level behavior described in the issue and verify that listed crates override the mode's level while unlisted modes and crates retain current behavior.

Written by the indexing model from the issue text.