Sundry efficiency issues for new incremental update branch

[johnwhitington]

First push ignores these for correctness only. But here they are for reference:

1. Decompressing an object also - is it intentional (and we want to keep it decompressed, or not?) If decompressing, using, and then recompressing without altering it should not count as altered!

2. Multiple updates seem to null out too many objects - from the first revision in the third revision, for example:

$ ./cpdf hello.pdf -update -rotateby 90 -o hello.pdf
$ ./cpdf hello.pdf -update -rotateby 90 -o hello.pdf

3. Changes to minimise update. For example, change_pages could preserve page numbers when only pages change. i.e when we just rotate one page...

4. Page-nulling? Can we just get rid of any null object when doing an update? Keeping nulls was in service of something else? What was it - just to avoid renumbering? Which we're not doing anyway? Best to avoid objiter at all on writing on account of it's too slow? Maxobjnum fix is to note when the largest object is deleted... but still could be wrong!

[johnwhitington]

Also: We should be reading lazily in all cases where update is in play, right?

[johnwhitington]

Can this just be fixed by, when were are going to be updating, checking that written objects are not identical and then un-marking them? We might still need some local fixes, but this approach might fix whole classes of problems?