Configurable `rules_rust`

Configuring compiler and linker flags in `rules_rust` currently relies heavily on imperative Starlark code (such as hardcoded `args.add` blocks inside the rule implementation) and bespoke build settings/transitions. Because flag-building is tightly coupled with the rule logic, consumers face high friction when adapting toolchain configurations to custom environments.

To resolve these customization barriers, compile and link flags should be decoupled from the core rule implementation and exposed as declarative configurations at the toolchain level.

* Enable declarative wrappers and flags without maintaining rule forks: Users should be able to inject custom compiler/linker wrappers, extra flag configurations, or alternative platform sanitizers declaratively at the toolchain level. This enables setting flags for project-specific workflows rather than adding more build settings directly to `rules_rust`, eliminating the need to carry custom patches or fork core rules (like `rustc.bzl`) and greatly simplifying upstream version upgrades.
* Support granular flag controls and custom compilation actions: The system should expose specific compilation sub-phases so that consumers can apply flags selectively based on the action type - such as targeting metadata-only builds (`.rmeta`), `clippy` checkout runs, etc. It should also enable support for spawning different types of compilation actions, such as emitting LLVM IR (`--emit=llvm-ir`) or LLVM bitcode (`--emit=llvm-bc`), based on user demands.
* Provide configurable and overridable artifact naming: Hardcoded platform-specific name mappings (like `.rlib` to `.a` static library symlinks or MSVC `.dll` vs. `.dll.lib` import conventions) should be decoupled and made configurable, making it easy to support custom platform layouts and exotic execution environments.