[draft] New PresaltedXorHasher, used for CoinsView map

[optout21]

PR bitcoin#35215 attempts to make the hash used by CoinsViewCache more efficient, by proposing to use an optimized version of SipHash. Here I explore the idea of stripping the hash down even further: simply XOR the various parts together. The new PresaltedXorHasher takes these parts: an 8-byte hash, the 4 8-byte parts of the TxId, and the vout (extended to 8 bytes), and XOR's them together (6 parts, 5 XOR operations). It's important to note that the TxId is itself a hash, so a simple XOR seems justified.

Performance micro-benchmark results: if master(PresaltedSipHasher) is 100% speed, 35215/(PresaltedSipHasher13Jumbo) is 200%, this(PresaltedXorHasher) is 440%.

Pros/cons:

Pro:

• Faster (by 4x)
• Simpler code

Cons:

• Not using battle-tested SipHash, needs to validate that simple Xor is suitable here
• The performance gain in the overall use case may be minimal.

See also: bitcoin#35215 (comment)

cmake --build build -t bench_bitcoin -j
build/bin/bench_bitcoin -filter=".*Hash.*"

|               19.06 |       52,470,089.08 |    0.1% |      0.01 | `SipHash24_36b`
|                9.64 |      103,720,894.10 |    0.4% |      0.01 | `SipHash13Jumbo_36b`
|                4.32 |      231,520,756.49 |    0.2% |      0.01 | `XorHasher6x8_2_36b`
|                1.69 |      590,690,707.99 |    0.7% |      0.01 | `DummyHasherFirst8Plus_36b`

[optout21]

Note: opened by mistake to main fork ( bitcoin#35305 )

[optout21]

Salt extended to 4x8 bytes. Following the comment bitcoin#31132 (comment) (thanks @l0rinc), the salt is now 4x8 bytes, and the 4 components are each XOR'ed with their salt, and the results added together. Performance is unchanged.

Also added a "dummy non-hasher" for benchmarking, establishing a floor in CPU time which cannot be improved upon realistically.