Updates to ZLibEstimator.

Use the current compression ratio to estimate how much space the uncompressed
tip is going to take up. This still overestimates a fair bit for gcc, but 
our responses are around 32kB instead of around 8kB. For bzr it seems to
occasionally under-estimate, but mostly over-estimate by a bit.
The only other thing I can think of, is to figure that if we're getting
really high compression ratios with zlib, assume we can do even better
with bz2. Note also, that gcc gets much closer to '64kB' each time
because we are often only searching a small handful of tips (often
even just 1), which means our granularity adding to the compressor
is very tight. By comparison, bzr is often searching 1000+ tips, and
we only have the option to add everything for the next step, or nothing.