Two major bug fixes and a new features:

Both of the bugs below occur when using tools on PDFs to add and delete pages. PDF encoders often have optimizations that produce funny xref tables and if they aren't properly handled, you get incorrect results.

### Bug Fix 1: Indirect Object Cache
The problem was with the indirect object cache. When we're looking for an indirect object whose target is a compressed object stream, we look at all of the objects in that stream, decode each one, and then add the object to the indirect object cache.  We decode and cache each object, even though we're only looking for one of the objects in the stream.  (It's possible this was originally an optimization). The problem is that, due to different cross references for different objects, the objects in one of the streams may not necessarily be the newest versions of the object. If we add it to the cache, we may be adding a bad object to the cache.

Here is a [test case pdf](https://www.sugarsync.com/pf/D62078_61165948_6795149).  The PDF has 7 pages. If you run the `getNumPages` on the PDF without the bug fix, it says there are 5.

### Bug Fix 2: Parsing the xref dictionary
The key bug that was fixed was in the loop near the "PDF 1.5+ Cross-Reference Stream" comment tag in read(). In the old code, values could be added to self.xref_objStm even though they already exist in self.xref[generation]. That should not happen because they will override the more up-to-date xref values. Instead of fixing this with a few lines of code, I cleaned up that section (which parses the xref dictionaries) and added comments.

Here is a [test case pdf]( https://www.sugarsync.com/pf/D62078_61165948_6741603). The PDF has 14 pages, but without the bug fix `getNumPages` says there are only 11.

### New Feature: mergeRotateAroundPointPage
I added the function `mergeRotateAroundPointPage`, which adds one page to another while rotating that page around a point.