Collections of strategies of generating the k * log(M) bits required for an element to
be mapped to a BloomFilter of M bits and k hash functions. These
strategies are part of the serialized form of the Bloom filters that use them, thus they must be
preserved as is (no updates allowed, only introduction of new versions).
Important: the order of the constants cannot change, and they cannot be deleted - we depend
on their ordinal for BloomFilter serialization.

See "Less Hashing, Same Performance: Building a Better Bloom Filter" by Adam Kirsch and
Michael Mitzenmacher. The paper argues that this trick doesn't significantly deteriorate the
performance of a Bloom filter (yet only needs two 32bit hash functions).