Refactor the huffman table selection mechanism for Bzip2 compression.

In the process, (temporarily) switches to a very simple method which always
generates two huffman tables, one from the global frequency distribution of
the block, and the other with a flat frequency distribution (ie, "no
compression"). (Previously we divided up the block into equal-sized chunks
and created a huffman table for each chunk, plus one more based on global
frequencies.)

Quick benchmark using the 'enwik8' input:
  C implementation of bzip2 -9: 29008758 bytes
  Previous huff table selector: 29302614 bytes
  Stupid 2-table method:        30578425 bytes

So good huffman table selection has an effect, but it's not a huge one;
about 3% for enwik8.
Use smarter huffman table selection mechanism for Bzip2 compression.

We now incrementally split the most-frequently-used huffman table, assigning
the half of its groups which result in the largest encodings to a new
huffman table, then recomputing all huffman tables.

Quick benchmark using the 'enwik8' input:
      C implementation of bzip2 -9: 29008758 bytes
      Previous huff table selector: 29302614 bytes
      Stupid 2-table method:        30578425 bytes
      New method:                   28995650 bytes