Investigate whether it is worth it to enable XXH3_128bit build ids in LLVM, Mold and Binutils.

[ermo]

Since #4570 and #4575 BLAKE3 hashes (truncated to 160 bits / 20 bytes) is now supported and is already a fair bit faster than SHA-1.

This issue is for documenting the speedup of XXH3_128bit vs. SHA-1 and BLAKE3 and then making a decision of whether this speedup is sufficient to make it worth pursuing.

See #1346 for context.

[ReillyBrogan]

Leaving my notes here for the future.

State of XXH3 support:

• XXH3 should be in binutils 2.44: bminor/binutils-gdb@2299dfd
• Mold doesn't support XXH3 at all (nor any other XXH variant)
• LLVM has the code to support XXH3_128 but it isn't used anywhere in the project outside of tests. The build-id code will need to be modified to work with XXH3_128 (which may be trivial, the LLVM code confuses me)

Other Notes:

• Mold and LLD currently break the input into 1MB chunks and then hash each one in parallel before hashing the hashes of the 1MB chunk hashes. They are thus not very likely to benefit much from XXH3 given that their build-id calculation is already very fast and they're probably bottle-necked by IO anyway (needs testing).
• Binutils (ld specifically) on the other hand uses only a single thread as far as I can see and if there's any improvement to be had it will likely show up here. I suspect it is also likely to be IO-bound however.
• I can't imagine that there won't be some benefit to XXH3 with these three, but if the benefit is < 2% or so of linking time my preference would be to keep with blake3 so that the build-id lengths are consistent.