improve immutable hash table on sequential inserts
improve immutable hash table on sequential inserts

Inserting keys with sequential hash codes --- as in 0, 1, 2, 3, etc.
--- performed badly compared to random keys, because it triggered the
worst case of allocation: allocate a node of size 1, then 2, then 3,
then 32, then 32 plus a subtree of size 1, then 32 plus a subtree of
size 2, and so on. By rearranging the bits in a hash code, arrange
for nodes that are more like 4-wide instead of 32-wide. In other
words, the tree become wider with thinner branches, instead of growning
just as a thick branch to the left.

Of course, there's now a different sequence of inserts that used
to perform well and now perform badly (the inverse of the new
reordering), but that case seems much more likely than the cae
of sequential inserts.

mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket,mafagafogigante/racket