crate_universe: bazel may fail to check for a repin when needed due to newly-added .rs files under a tests/ directory

## The issue
* For packages which get their external dependencies via a `Cargo.toml`, if a new rust file is added to its `tests/` directory, this changes `cargo-bazel`'s computed hash, due to the metadata associated with that `Cargo.toml` changing.
* Since the newly-added file is not a dependency of the `determine_repin` action, `cargo-bazel query` is not necessarily re-run if it was run before the file was added.
## Reproduction
https://github.com/silas-enf/cargo-bazel-repin-issue has a minimal reproduction.
## Expected behavior
Either crate_universe doesn't care about `.rs` files in the local tree, or it causes bazel to error immediately with a "repin needed" message after one it cares about is introduced.
## Actual behavior
crate_universe needs a repin after `.rs` files are added to `tests/` for a package with a `Cargo.toml` which crate_universe is tracking (verified by running `cargo-bazel query` manually, see the repro), but this need for a repin is not necessarily caught by bazel.
## Possible workarounds
* I believe (but have not yet tested) that moving from Cargo.toml files to specifying dependencies directly to the `crates_repository` would get rid of this issue, since it seems to be rooted in the `Cargo.toml` metadata tracking.
* Adding `autotests=false` to `Cargo.toml` disables cargo's automatic tracking of `.rs` files under the `tests/` directory, preventing files there from affecting cargo-bazel's calculated hash.
## Notes
I believe this is a caching issue -- it seems that bazel is not seeing any need to rerun the `determine_repin` step due to a previous run having already succeeded. Unfortunately, I haven't been able to determine where this caching takes place -- I've tried cleaning the `repository_cache` and `disk_cache`, as well as running `bazel shutdown` to restart the server, and none has reliably forced the repin check to be run again.

This can lead to unfortunate issues where the need for a repin doesn't cause failures until someone else tries to build the change -- particularly in cases where the cache in question is shared, and cargo-bazel is only run again after the cache entry gets evicted by other means.