Favour rarely-seen wells

[qntm]

This is a minor alteration to the behaviour of the HATETRIS AI. This change is intended to mitigate an extremely unlikely potential future scenario where an attacker has found a "seven-fold loop", where, from the current well, any provided piece can be placed in such a way as to lead to a repeat well.

Previously, HATETRIS' behaviour in this scenario was to treat "previously seen well" and "previously unseen well" as a binary. Either a piece leads to a previously seen well or it doesn't.

• If none of the pieces leads into a previously seen well, that's a tie, and we revert back to the usual height-checking logic.
• If one of the pieces leads into a previously seen well, we choose one of the other six.
• If six of the pieces lead into previously seen wells, we choose the seventh.
• And, if all seven pieces lead into previously seen wells, the fabled seven-fold loop... well, that's a tie once again, and we revert back to the usual height-checking logic.

But what if we count how many times each well was seen? What if Z, O, I, J, L and T can all lead into a well which has been seen only once, but S can lead into a well which has previously been seen 19 times? With the older logic, HATETRIS considers all seven pieces to be tied, and with nothing else to break the tie, returns an S. This most likely leads into a 20th repeat of that one well. This would indicate a true loop, and a busted algorithm.

With the new logic, HATETRIS keeps count of how many times each well has been seen, and uses the number of times seen to break the tie. In this example scenario, HATETRIS would now return a Z.

Per my unit tests, this change preserves existing behaviour for all known scenarios and existing replays. I think this tie-breaking logic is exceedingly unlikely to ever be exercised in practice, although I have added a rigged unit test for it.

I believe that this change means that HATETRIS, if played for long enough, ultimately either (1) kills you, or (2) demonstrates every single possible piece sequence, which, per Brzustowski, kills you. This makes the HATETRIS algorithm provably undefeatable (I think), a property it previously conspicuously lacked.

[qntm]

This is the fourth iteration of the HATETRIS algorithm. The first iteration had no loop-prevention logic. The second iteration tracked previously-seen wells in such a way that it would wait for a repeat and then return a different piece in order to prevent the loop continuing - forcing a repeat well was still possible. The third iteration simplified the logic to avoid returning a piece which could even theoretically be placed in such a way as to lead into a loop, making forcing a repeat well almost impossible on paper.