Initial value of `FxHasher` leads to avoidable collisions

It's easy to see that FxHasher { hash: 0 }.add_to_hash(0) is a fixed point (i.e. does not result in any change to the internal state self.hash):

https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L76-L81

In particular 0.rotate_left(5).bitxor(0).wrapping_mul(K) == 0.

Therefore initialising FxHasher with a hash value of 0 is a bit undesirable, as sequences of 0s (written to the hash before any non-zero value) cannot be distinguished by their hashes.

https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L69-L74

Of course, there's always the possibility that a value of self.hash.rotate_left(5) could be written to the hasher, which will result in the internal state reaching 0—but in practice writing values of 0 can arise quite often, and choosing some other initial value would be quite beneficial? Perhaps even K?

Start in src/lib.rs at the linked FxHasher initialization and add_to_hash implementation around lines 69–81. Examine the consequences of choosing a nonzero initial state and determine how leading zero inputs should behave. Done means the selected initialization avoids the described fixed point without introducing an unintended hash compatibility change.