opt_merge: hashing performance and correctness

[widlarizer]

This is a direct remake of #4175 sans the 64-bit hash value. I'm making use of the interface in #4524 and requiring that PR (and containing its commits at the moment). Instead of xorshifts, values are sorted, though a final xorshift is included as a part of the fudge (--hash-seed=N) mechanism.

Additionally, I discovered opt_merge behaves incorrectly in the case of hash collisions. This suggests that this PR might in rare cases bring improvements in quality of results for flows that use opt_merge, since prior to it, hash collisions would inhibit merging. I modified the sharemap from a dict<hash_t, Cell*> to an equivalent std::unordered_multimap so that multiple cells can be associated with the same hash. This can't be a separate change since this bug actually broke the build just by changing how the hashes are constructed.

Sorry for the spam to code owners due to being based on the above mentioned wide-reaching PR #4524, I don't have a way of removing you from the reviewer list. The diff for this PR is not going to be very readable on github either until that's merged

[widlarizer]

The current implementation regresses opt_merge runtime many times over. I'll see if std::unordered_multimap is salvageable.
Currently, std::unordered_multimap, as I use it

• maps from hash_t to Cell*
• hashes hash_t with std::hash (unnecessary)
• compares Cell*s with pointer equality

Instead it should:

• map from Cell* to Cell*
• hash with hash_cell_function
• compare with compare_cell_parameters_and_connections