Add warning replay to bazel build and aspects

### Description of the feature request:

Actions, for example C++ compile actions, can produce a lot of output on stdout / stderr which contains important information like compiler warnings. Bazel shows this output when the action is executed, but not when the result comes from a cache. This is also true for e.g. aspects which lint the code and produce warnings.

There should be a flag to replay the stdout / stderr of actions and aspects which come from the cache, which would otherwise not be shown.

A flag like this has existed in the past under the name `--experimental_replay_action_out_err`. It was requested in [Don't hide compilation warnings - Issue #8023](https://github.com/bazelbuild/bazel/issues/8023) and implemented experimentally in [Commit f20b33c
](https://github.com/bazelbuild/bazel/commit/f20b33c968ff7b5bdfbb5676aa730a5f9c5e4012). Four months later a problem was reported where when the flag was combined with `--test_output=all`, sometimes old + new output would be printed together; see [experimental_replay_action_out_err causes out of order execution - Issue #11365](https://github.com/bazelbuild/bazel/issues/11365). This issue was then "fixed" by removing the replay flag again in [Commit f588351](https://github.com/bazelbuild/bazel/commit/f588351abdde4561a594b23b49c4479907ffa547).

Please reintroduce warning replay with semantics that avoid the earlier problem:

- Never replay output if the action executes during the current run. The output should appear exactly once.
- Only replay output of actions which would have been executed for the current target. Output unrelated to the current target should not appear.

Perhaps this could be done similar to `--test_output`, in the form of a configurable `--build_output` and `--aspect_output` flag.
Both new flags could have, for example, settings like this:

- `uncached` (default) current behavior where only non-cached results are printed
- `all` to print all cached and uncached results from stdout and stderr

More features could be built on top of this. For example, a `filtered` setting to filter the output of actions to only show those containing at least one `warning: ` or `error: `.
Also, text coloring is an important part of warning readability and should be kept throughout replay.

Documentation for `--test_output`: [user-manual](https://bazel.build/docs/user-manual#test-output) and [command line reference](https://bazel.build/reference/command-line-reference#build-flag--test_output)

### What underlying problem are you trying to solve with this feature?

In a large codebase with many existing compiler warnings, or when new warnings are enabled, developers lose visibility into warnings from unchanged files unless they perform an expensive clean rebuild.
Cleaning up warnings becomes difficult. Developers need to either work with potentially outdated warnings from a stored log file, or they need to constantly pay the cost of a recompile, instead of getting the results from the cache.

There are workarounds, like using a wrapper around the compiler or linter to pipe stdout and stderr to a file, declaring that file as an output of the action, and then wrapping the bazel build call with a script which reads that log file and replays it to the console. It might also be possible to parse the BEP and gRPC logs to achieve a similar result. But these are both a lot of effort for something that, in my opinion, Bazel should just do for you.

To my knowledge, IDEs do not solve this problem either. VSCode with the Bazel extension for example, clears the list of warnings and errors when the project is rebuilt. It only shows the ones from the most recent build.

Filtering the output would be nice because e.g. linters like to print summaries of their results, even if they didn't find anything. So when a linter aspect runs on every file of a target, it might produce a summary for every file touched. That is a lot of noise if there are only a handful of actual warnings.

Review the historical --experimental_replay_action_out_err implementation in commit f20b33c and its removal in f588351, then compare the documented --test_output behavior in the user manual and command-line reference. Define --build_output and --aspect_output semantics so cached output is replayed only for actions selected by the current target and never duplicated for actions that execute during the run.

Written by the indexing model from the issue text.