Compress chert postlist changes buffered in memory

[olly]

If we could somehow reduce the memory used by the postlist changes chert buffers, we could buffer more and/or let the OS have more spare memory for buffering disk blocks. That should allow indexing to run faster. However we need to compress in such a way that we can still implement Xapian::Database methods including the effects of the buffered changes.

[olly]

This is really a candidate for flint, not quartz now.

We *can* fairly easily compress in the common (and speed critical) case of appending documents by simple storing a sorted list of entries for each term (probably in the same format we use on disk) as we're always appending to it.

If we keep the existing map, we can handle the pure modification case, and also a mixture of modifications and updates.

[olly]

This is a patch which adds a quick hack implementation:

http://www.oligarchy.co.uk/xapian/patches/xapian-faster-flint-add-document.patch

It probably won't apply cleanly to SVN HEAD, it disables replace_document() and delete_document(), and it could store the appended changes in a much more compact way, but even this crude approach was measurably faster (I don't recall the exact figures, but something like 10-15% I think).

[olly]

This doesn't require API or ABI changes, so can go in 1.0.x.

[richard]

(In #120) Remove the unfixed dependencies so we can close this bug - they're all marked for the 1.1.0 milestone.

[olly]

Update to refer to chert rather than flint or quartz.