Ensure monotonicity of xref-section size
Bug 694382: Fix problems arising from recent pdf_obj changes.

Thanks to zeniko for spotting these problems.

When we close a document, purge the glyph cache to ensure that
no type3 glyphs hang around with pointers to pdf_obj's that
are now gone.

Pass doc to pdf_new_obj_from_str rather than NULL. We believe
that the reason this needed to be NULL is no longer valid.

Also, revert to using an int for ref counts.

In a quick test of our regression suite we only found 2 files
that ever made a refcount > 256 (and they never got larger than
768), but the potential is there for issues. Reverting to an
int until we can think of a better idea.
Move to using a flags bit rather than "Dirty" dict entries.

Correct the naming scheme for pdf_obj_xxx functions.
Modify FZ_NORETURN to work on MSVC too.

We need to have it as a prefix, not a postfix now, but it should
work on both gcc and MSVC now.
Optimise xref-section extension and improve linked list creation
Ensure altered objects are moved to the incremental xref section
Fix merge mistake.
Add array_insert_drop and array_delete functions.

Also add index argument to array_insert.
Fix android app crashing after save

Make pdf_specifics callable with a NULL doc, as was fz_interact, which
it replaces.
Bug 694382: Fix use-after-free due to type3 fonts.

Thanks to zeniko for spotting the problem here.

Type 3 fonts contain a reference to the resources objects required
to render the glyphs. Traditionally these have been freed when the
font is freed. Unfortunately, after recent changes, freeing a PDF
object requires the pdf_document concerned to still exist.

While in most cases the type 3 resources are not used after we have
converted the type3 glyphs to display lists, this is not always the
case. For uncachable Type 3 glyphs (such as those that do not
completely define elements in the graphics state that they use, such
as color or line width), we end up running the glyphs at interpretation
time.

[ Interpretation time = when doing a direct render on the main thread,
or when creating a display list - so also on the main thread. No
multi-threading issues with file access here. ]

The fix implemented here is for each pdf document to keep a list of
the type3 fonts it has created, and to 'decouple' them from the
document when the document is destroyed. The sole effect of this
decoupling is to remove the resources (and the PDF operator buffers)
from the font. These are only ever used during interpretation, and
no further interpretations are possible without the document being
alive anyway, so this should have no net effect on operation, other
than allowing cleanup to proceed cleanly later on.
Fix "mutool clean -ggg" operation.

When moving an object from one xref to a new xref, ensure firstly
that we only drop each object once (by setting it to NULL) and
secondly that it has the correct parent pointer.
Avoid spurious, broken-annotation warning when appearance stream missing
Rename pdf_set_objects_parent_num to pdf_set_obj_parent
Update Memento to output to debug window on windows.

Windows is stupid and doesn't display stderr/stdout in the debugger.
Update Memento so that messages will appear there too.
Update fz_error/fz_warn to output to Debugger window on Win32 too.

Stupid windows debugger doesn't show stdout/stderr anywhere in
non console apps, so add code to make errors/warnings visible.
Avoid fz_throw/message on every annotation without appearance.

Annotations can sometimes not have appearance streams (such as
Links). Avoid spewing messages to the console about this. Also
avoids overhead of throw/catch each time.
Update pdf_write_document to support incremental update
Fix up of a few issues in the project settings for winrt
Update of winrt solution files for the reorganization that was recently undertaken
A minor path fix in winrt solution.