`rust_prost_library` rules not affected by `--@rules_rust//rust/settings:rename_first_party_crates`

I haven't had any major collisions _yet_, but it's only a matter of time until I'm forced to rename something so I can extend the rust to cover some protos that python and cpp deconflict using the package path.

A flag to tell Prost to knock off the module path might also be nice - right now my protos end up named things like `command_proto_rs::protocols::oi::CommandProto`, which is kind of silly. The unique part of the path is _behind_ the conflicts!

(I'm guessing that most people group their rust into crates even when running under Bazel, re-exporting their generated protos instead of making clients depend directly. I generally insist on keeping `rename_first_party_crates` on and using direct deps because essentially every horrible-build-time project I've ever worked on has gotten that way because people used globs and everything-in-one-target libraries instead of strictly enforcing one file per target. Multiple files per target is how you end up rebuilding the world every time you so much as look at your codebase. But Rust seems to be trying _really_ hard to break that, what with the orphan rule and now this...)