Support the GCC 12.1+ gcov format in the built-in reader, and read a gcno's gcda in parallel

[michieldwitte]

The built-in gcno/gcda reader only understood the format up to GCC 11, so anything newer failed to parse and coverage had to go through gcov instead. On GCC 15.2 output, master errors with Not enough data in buffer: cannot skip 10804527104 bytes and reports nothing at all.

GCC 12.1 changed three things: the gcno and gcda header carry a checksum after the stamp, lengths count bytes instead of 4-byte words and strings lost their padding (so records are no longer 4-byte aligned), and a negated record length marks counters that are all zero and left out. The reader now handles all three, keyed off the version it parsed, so older files are read exactly as before. Since records can now be unaligned, integers are read from their bytes rather than through a transmuted pointer.

The second half is performance, on that same reader. With one gcda per test run against a single build, the producer read them one at a time while the parsing threads waited: 501 translation units over 174 runs spent 1.06s reading 87k gcda (681 MB), and varying --threads from 1 to 16 made no difference at all. They are now read with rayon when the archives are plain directories, and the directory walk no longer opens every file it finds, since only gcno, info, dat, xml and out are ever sniffed. The same 681 MB now takes 0.64s. rayon was already a dependency.

Tests: gcc-11, gcc-12 and gcc-15 reader fixtures in the existing style plus one for the omitted zero counters, and version assertions on both sides of the 12.1 boundary. The golden dumps for gcc-9 through gcc-15 are byte-identical, so the same program parses to the same model across the format change. The parallel read has unit tests for buffer order and for falling back when an archive is a zip. cargo fmt --check and clippy are clean, and 142 tests pass — the 4 llvm_tools failures want llvm-profdata installed locally and fail the same way on master.

On a real C++ project (GCC 15.2, coverage from 174 separate test runs) the built-in reader reports the same 64.8% whether the runs are merged with gcov-tool merge first or passed in unmerged, so the merge step can be dropped entirely.