
bzip_compressBlock does check that the output will fit into
the specified space, but only after creating about 1k of
output first.  So e2compr must ensure that at least 1k
of output space is available before calling bzip_compressBlock.

bzip_decompressBlock *ignores* the output space indication
passed by e2compr, and just assumes that N_BLOCK bytes
of space are available to decompress into.  Does this matter?
It also ignores the input buffer size indication, since 
it the end-of-block is detected by interpreting the compressed
bitstream.

Compression of very repetitive blocks can be quite slow.  
Blocks which compress too slowly are heavily randomised;
this limits the max compression ratio to about 15:1.  Most
blocks are unaffected, tho.
