`<unordered_meow>`: Should we detect bogus hash/equivalence combos?

WG21-N4971 [unord.req.general]/5:

Two values k1 and k2 are considered equivalent if the container’s key equality predicate pred(k1, k2) is valid and returns true when passed those values. If k1 and k2 are equivalent, the container’s hash function shall return the same value for both.

This is a very important requirement - violating it will corrupt the unordered associative containers, which can be hard to track down later. (Note that the requirement is one way. Equivalent elements must imply identical hashes, but identical hashes need not imply equivalent elements - that's just a hash collision, which degrades performance but not correctness. It sure is funny when someone writes a hash that returns bool, though.)

For the ordered associative containers (and sorting functions), our _Debug_lt_pred() machinery detects bogus less-than comparisons, which have the same potential to corrupt data structures and break algorithms.

We should consider implementing similar debug checks for hash/equivalence. This could affect debug mode perf, which users might notice as a significant regression, so we should consider skipping such debug checks for known combos (e.g. unordered_set<int> should pay zero additional costs), similar to #4377 which I just filed.

Start by reviewing the existing _Debug_lt_pred() machinery for ordered associative containers and sorting functions, then compare the proposal with issue #4377. Investigate how debug checks could cover hash/equivalence requirements without regressing known combinations such as unordered_set. Done means an agreed design and performance approach.