This PR adds a `compile_well_known_types` flag to the Prost toolchain
declaration.

By default, for backwards compatibility reasons, this flag is set to
`True`, as this is the current behavior. If this flag is switched to
`False`, the `compile_well_known_types` option is no longer passed to
Prost and Tonic, and the protoc wrapper will ignore types from the
`google.protobuf` package when computing external types, relying instead
on [prost's own externals
handling](https://github.com/tokio-rs/prost/blob/e617832ab432adc7dd799321eb216c82a589d421/prost-build/src/extern_paths.rs#L35-L62).
Furthermore, the configured Prost types crate will be added as a runtime
dependency to all `rust_prost_library` targets.

We're currently migrating away from our own set of proto rules to
`rust_prost_library`, but our existing code relies heavily on the
`prost-types` crate's implementations of well-known-types, which is the
recommended way of using prost. However, the current behavior of
`rules_rust_prost` makes it impossible to wire up properly, hence this
PR.

Fixes #2058

---------

Co-authored-by: UebelAndre <github@uebelandre.com>

It's not clear why windows is disabled from this. Gonna enable it so
developers can give it a try.

@UebelAndre my last MR got in a funky state due to the github rev pin of
crates-index. I opted to just redo the MR instead of fighting the
rebase.

Fixes[ issue](#3349)

Tested and verified

Since our testing mostly uses bzlmod these days, we've currently
regressed in this coverage.

This introduces a small re-implementation of
https://crates.io/crates/temp-env while keeping the tests free of
dependencies. This should make it substantially easier to write
meaningful tests for runfiles.

All flags were treated as accepting a parameter, causing any argument
following a parameterless flag (e.g. `-no-standard-includes`) to be
passed through. This causes bindgen failures if the next argument isn't
supported by clang.

`-nostd*` flags has also been expanded using
https://clang.llvm.org/docs/ClangCommandLineReference.html to make it
clearer that these flags are parameterless. Since these flags resulted
in a prefix match, not a full match, they wouldn't set `open_arg = True`
and therefore wouldn't cause issues, but this behavior is unnecessarily
subtle now that there are two lists.

Fixes #3359

https://blog.rust-lang.org/2025/03/18/Rust-1.85.1.html

closes #3297