Aside from maybe a latency win in the loop, this means that when we find a
short match, we've already done the hash we need to check the next long match.

This costs a little ratio, unfortunately.

Since we're now hashing the position ahead even if we find a long match and
don't search that next position, we can write it back into the hashtable even
in long matches. This seems to cost us no speed, and improves compression
ratio slightly!

This lookup can be advanced to before the short match check because either way
we will use it (in the next loop iter or in `_search_next_long`).

This test depended on `_extDict` and `_noDict` compressing identically, which
is not a guarantee we make, AFAIK.