Updated MuPDF Android app from Paul Gardiner.
Update android app to use document interface

This adds XPS and CBZ support for free.
Remove "MuPDF" title bar on Android app.

Simple change to the XML.
Android tweaks; attempt to trigger on .xps and .cbz files too.

In theory, the changes here should make mupdf be recognised as
a handler for .xps and .cbz files (and for .pdf files without
the correct mimetype). In practise I can't actually make this
work right on my device. I'll open a stack overflow question
and ask there.
Go back to using a direct fade animation in favour of the ViewAnimator
Android app: implement Tor's request to clamp vertical position when height within screen
Android app: make taps on side margins move to next and previous
Remove android/local.properties from the git.

Seeing as it has local configuration, it should not be version controlled.
The android manual says so.
Android app: decode the uri before using as a file name
Use a fixed duration of 400ms for scroll animation.

Make fade in/out animations 200ms long, the same as the default animation
duration for iOS UI animations.
Add new Android button icons and tweak the layouts.
Android app: react to "Done" button when searching
Add android temporary files to .gitignore
android app: slide buttons on instead of fading
Replace Android application icon with one based on the logo.
Set default DPI in jpeg images if the file says 0.
Tweak animations and colors.
Fix a double free on an error path.
Rework image handling for on demand decode

Introduce a new 'fz_image' type; this type contains rudimentary
information about images (such as native, size, colorspace etc)
and a function to call to get a pixmap of that image (with a
size hint).

Instead of passing pixmaps through the device interface (and
holding pixmaps in the display list) we now pass images instead.

The rendering routines therefore call fz_image_to_pixmap to get
pixmaps to render, and fz_pixmap_drop those afterwards.

The file format handling routines therefore need to produce
images rather than pixmaps; xps and cbz currently just wrap
pixmaps as images. PDF is more involved.

The stream handling routines in PDF have been altered so that
they can recognise when the last stream entry in a filter
dictionary is an image decoding filter. Rather than applying
this filter, they read and store the parameters into a
pdf_image_params structure, and stop decoding at that point.

This allows us to read the compressed data for an image into
memory as a block. We can then restart the image decode process
later.

pdf_images therefore consist of the compressed image data for
images. When a pixmap is requested for such an image, the code
checks to see if we have one (of an appropriate size), and if
not, decodes it.

The size hint is used to determine whether it is possible to
subsample the image; currently this is only supported for
JPEGs, but we could add generic subsampling code later.

In order to handle caching the produced images, various changes
have been made to the store and the underlying hash table.

Previously the store was indexed purely by fz_obj keys; we don't
have an fz_obj key any more, so have extended the store by adding
a concept of a key 'type'. A key type is a pointer to a set of
functions that keep/drop/compare and make a hashable key from
a key pointer.

We make a pdf_store.c file that contains functions to offer the
existing fz_obj based functions, and add a new 'type' for keys
(based on the fz_image handle, and the subsample factor) in the
pdf_image.c file.

While working on this, a problem became apparent in the existing
store codel; fz_obj objects had no protection on their reference
counts, hence an interpreter thread could try to alter a ref count
at the same time as a malloc caused an eviction from the store.
This has been solved by using the alloc lock as protection. This in
turn requires some tweaks to the code to make sure we don't try
and keep/drop fz_obj's from the store code while the alloc lock is
held.

A side effect of this work is that when a hash table is created, we
inform it what lock should be used to protect its innards (if any).
If the alloc lock is used, the insert method knows to drop/retake it
to allow it to safely expand the hash table. Callers to the hash
functions have the responsibility of taking/dropping the appropriate
lock, and ensuring that they cope with the possibility that insert
might drop the alloc lock, causing race conditions.
Add fz_trim_buffer function, and call it.

Remove stray space at the end of buffers.