feat: clang-tidy emit action per file to lint

[molar]

Some cc_library/binary targets may contain 10+ files listed in sources and as clang-tidy runs single threaded, this can lead
to long running linting actions. This PR emits a clang-tidy action per source file, so they can be parallelised locally/remotely. The stdout/stderror is merged in unspecified order according to the order of the srcs using a simple
concatenation. The exit_code of the individual action, is merged by sorting them numerically and selecting the highest number.

I did also consider making the splitting optional, in case we are unsure of the impact of this change. Let me know if i should do that.

I also considered updated the progress message to use the source file short path instead, but decided to leave it out here. Currently the progress message will be the same for each individual action and makes it harder to see which source file is being linted.

Test plan

• Covered by existing test cases
• Manual testing was also done, both in our own bazel repo and in the examples folder. It has only been tested on linux, so there could be issues with the behaviour of sort and head on macOS.
• I would like some guidance on testing the fix part as we do not use the aspect wrapper in-house

[molar]

Friendly ping @alexeagle do you have some input or can you kindly suggest a reviewer?

[alexeagle]

I'm sorry - I looked through this once and then got in my head that it was blocked on something.

It's a bit complex/gross to have to merge the exit codes back together this way. like you say, it's using non-hermetic system tools, plus space delimiting is risky when filenames can have spaces, so may need some quoting work.

Is it possible to move the splitting earlier? I'm imagining the aspect visits a cc_library target and produces an action per file at that point. Bazel sees all the actions and can react to the non-zero exit code(s) itself. I think there's no need to aggregate the results back to the library level, right?