Fix for bug #695229 - open document from byte array doesn't work, but saving to file and open from file works

Patch was supplied by gong_su@hotmail.com. Thanks!
Prevent the creation/destruction of the fz_cookies from trampling the env/clazz pointers in globals.

The env/clazz pointers are stashed in the globals structure so that they can
be accessed by callback functions in mupdf.c (such as bufferStreamSeek()).

The intention is that only one thread (i.e. the AsyncTask background thread)
reads/writes these stashed pointers. Because cookies are created/destroyed
in the main thread, we add a new version of get_globals() which doesn't trample
these pointers.
Fix for pages being repeated when running on Android Honeycomb.

Fixes bug #695191 - Mupdf Build49/armv7a & Android 3.1: cycles
through subset of pages & page scrubber

The problem here was that in Honeycomb, various bitmap operations
(including drawing via JNI) do not update the bitmap generation count.
When hardware acceleration is enabled, this means that the underlying GL
layer is not aware that the bitmap has changed, and ends up reusing old
textures.

To workaround this, we erase the bitmap before drawing the page. Erase
appears to be the only operation I could find (after pouring through the
source), which actually increments the generation count. The other option
would have been to disable hardware acceleration, but that was far less ideal.
Fix various Xcode analyzer warnings.

Most were pretty harmless, and were addressed by renaming functions to match the Core
Foundation naming conventions, but there was one actual memory leak, and some potential
uses of uninitialised data.
Add missing 'period' to files launched via 'Open In' before file extension.

Fixes bug #694711. As far as I could see, opening an XPS worked fine, the
first time. However, if the same file was opened a second time, then it
should have been saved with a number, e.g. foo(1).xps. However, the period
was ommitted, so the file wasn't recognised as an XPS.

This presumably wasn't an issue for PDF files, as PDF format is assumed
by default (I am guessing).
Fix deleting wrong file or crashing app if first file deleted.

Correct an off-by-one error in the file deletion code.
Add missing fz_var() and fix potential memory leak.
Fix some compiler warnings on Android.

Use intptr_t when casting between a jlong and a pointer to suppress errors
about different size words.

Add a 'u' suffix to unsigned values output by the cmap dump utility.
Partially revert "Add missing fz_var() and fix potential memory leak."

(Revert the fix for potential memory leak - there wasn't a potential memory
leak as the device only takes ownership of it's display list if
dev->free_user is set).

This reverts commit ada560eb015e7b2208c492d47f28da8093733c4a.
Fix #695217 - don't allow annotation of encrypted PDFs
iOS - Fix #695217 - don't allow annotation of encrypted PDFs
Switch to Artifex Team.
Fix coding style issues and remove C99 mid-block declaration.
Remove some trailing space.
Bug #694104 - Allow using MuPDFReaderView from GUI layout tool.

The GUI layout tool instantiates custom controls classes to display a
preview in the IDE. It relies on the 2-argument constructor being
implemented.

Use a different means to get the window manager that works for non-activity
contexts, and avoid creating gesture recognizers in this situation.

Based on a patch supplied by Masaki Muranaka
Fix bug #695346 - iOS app does not register to open CBZ files.

Use the UTI 'public.cbz-archive' instead of the more generic
'public.zip-archive'. It's likely another app (or the OS) has an
Exported UTI for 'public.zip-archive' which would take precedence over
our Imported UTI and not have a 'cbz' extension.

It's not entirely clear what the correct UTI to use for CBZs is (there
are a few), but public.cbz-archive seems to be most likely candidate.

Remove the 'zip' extension, as we probably don't want to load arbitrary
zip files.

Add mimetypes for all completeness, and separate OXPS from XPS as it has
a different mimetype.
Fix opening files from Email app.

On 2.3.x, opening files from the Android email app (not Gmail), was causing
a crash due to a SecurityException. On 4.x, it was failing with an error
message.

I think we should have just been calling
getContentResolver().openInputStream(uri) to get the file data, rather than
reading the row from the content resolver and looking at the _data field.
On 2.3.x querying this row caused a security error. On 4.x, we got back
a _data field containing a path, but this path was internal to the email
app, and not for our consumption.

Previously we were calling openInputStream() only as a fallback; now we try
it first, and fall back to the other method if that fails. I suspect we can
delete the other code, but I can't test on the 3.x version of the Transformer
Prime, so I'm leaving it be for now.
Pass mimetype when opening a document from a stream.

Fixes opening non-PDF files from email programs that use a ContentProvider
to supply attachments.
Handle the application/xps mimetype.

I think this is non-standard, but some applications seem to use it.

The email app on Android uses it, despite the fact the original email
actually embedded it as application/octet-stream. I guess the email app
is looking at the filename.
Fix incorrect syntax for class names in JNI.

Causes a crash on Android L/ART.