Reason: bazel-zig-cc invokes zig cc. Bazel takes care of parallelism itself, so it will assume zig is a "simple" command that uses a single core. It is not, however.

On many-core machines this leads to many parallel processes using many cores. Thus we should use zig cc -j1 (or equivalent) in bazel-zig-cc. Otherwise the number of jobs multiples quickly. (Unfortunately, Bazel neither supports jobserver nor can limit the number of downstream cores via cgroups or similar.)

I have almost implemented -jN, --jobs=N like this:

1. ThreadPool.init() accepts a new argument jobs: ?usize
2. If jobs is set, uses that variable for thread_count, otherwise the behavior is as before.

And interesting questions ensued:

1. Is -jN, --jobs=N a reasonable argument to add to zig cc, zig build-* et al?
2. This would be the first option that clang does not accept (technically, not in clang/include/clang/Driver/Options.td). Is this OK as a precedent to have zig cc options that are not valid clang options? I can also do this go-style via ZIGMAXPROCS. :)

EDIT: removed a long question about two thread pools in src/test.zig, that was somewhat answered in a commit message where they were introduced.