`build_test` shows test as cached even if the build was not up-to-date

This makes it hard to tell at a glance which targets had to get rebuilt in a given test invocation without examining the profile. I believe this happens because the test creates [an intermediate target as input to the no-op test](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/build_test.bzl#L108-L118). Since that target is the same regardless of srcs, the test rule itself detects that its inputs didn't change, and thus shows "cached".

One sample usage of `build_test` is to make sure a typescript typechecking target is up-to-date. The RBE size concerns don't apply there, because any typescript library using this target as a dependency already needs to be able to load all the output typings that are being verified by `build_test`.

I had a few possible ideas for improving this:
1) Output a random number or the current timestamp or something similar to the intermediate targets to force the test to run when inputs change
2) A more-deterministic option is to hash all the inputs together but that might have perf implications
3) Remove the batching behavior and associated intermediate outputs
4) Make the batch size configurable and avoid batching if the number of files is small enough to fit in a single batch. Typescript rules can set the batch size to the number of outputs to effectively disable the batching.

Thoughts?

Start by reading rules/build_test.bzl, especially the intermediate-target logic at lines 108-118, and reproduce the cached status with the described build_test usage. Compare the test result with the profile to confirm when inputs were rebuilt. Done means build_test accurately distinguishes cached tests from invocations whose inputs required rebuilding.

Written by the indexing model from the issue text.