When throwing an error during fz_alpha_from_gray, the stack depth
can get confused. Fix this by moving some more code into the
appropriate fz_try().
In the course of fixing this bug, I added some new optional debug
code to display the stack level as it runs. This is committed here
disabled; just change the appropriate #define in draw-device.c to
enable it.
Also, add some code to run_xobject, to avoid throwing in an fz_always()
clause.

Return the null object rather than throwing an exception when parsing
indirect object references with negative object numbers.
Do range check for object numbers (1 .. length) when object numbers
are used instead.
Object number 0 is not a valid object number. It must always be 'free'.

Replace the DroidSansFallback TTF files with a TTC that has two fonts:
The original and a copy where the OpenType 'vert' substitution
lookup has been pre-applied by copying the uniXXXX.vert glyph data
to uniXXXX.

If we hit an out of memory error in fz_draw_end_mask, then pop the
stack, and rethrow. Ensure that the generic device code catches this
error and sets the error_depth to 1 so that the final pop is ignored.

Various functions (such as fz_begin_group) handle errors internally
by use of the error_depth parameter. This means that if we call
them, we MUST ensure that we call the appropriate closing function.
Similarly, if we don't call them, we should NOT call the closing
function.
In order to ensure we do this correctly, we introduce a cleanup_state
variable that says which ones we tried to call.
This cures the original bug.

We used to extract the outline using the combined TM*CTM matrix and
use the identity transform for stroking, thus ending up with the wrong
line width.
If we instead extract using the TM and then stroke with the CTM we get
the correct results.

When I changed the stream implementations to use implementation
specific buffers, rather than a generic public one in every fz_stream,
I changed fz_read_byte to only get a single byte at a time.
I noted at the time that the underlying stream was free to decode
larger blocks if it wanted too, but I forgot to actually do this for
the flate decoder. Fixing this here should solve the speed issues.