Bug 694894: Avoid throwing away an object while in use.

When we call to execute a pattern, we clear out the pdf_csi (the
interpreter state). This involves clearing the stack and throwing
away the record of the object we have just parsed.

Unfortunately, when filling glyphs with a pattern, that object is
still in use. We therefore amend the pdf_run_contents_stream to
safely stash the object away and restore it afterwards.

This solves this problem, and protects us against any other similar
problems that might also arise.

This solves:

  b8e2b57991896bf8120215cfbf7b54bb_asan_heap-uaf_86064f_2362_2587.pdf

Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
disable JPEG decoding speed-ups to prevent artifacts

Using JDCT_FASTEST as rendering method can produce visible artifacts
(e.g. in 1960_-_DCT_image_wrongly_decoded_regression_from_1.2_.pdf).
fix memory leaks in pdf_load_jpx and fz_new_image_from_pixmap

fz_new_image_from_pixmap expects that the pixmap's colorspace has two
references which is contrary to expectations. If it instead addrefs the
pixmap's colorspace, the only caller pdf_load_jpx can consistently
drop the colorspace after passing it to fz_load_jpx.

Also, if the contract is that whatever is passed into
fz_new_image_from_pixmap belongs to the new image, then the pixmap also
has to be dropped on error so that it isn't leaked.
Revert change of mupdf.sln from VS2005 format to VS2012.
Bug 694957: fix stack buffer overflow in xps_parse_color

xps_parse_color happily reads more than FZ_MAX_COLORS values out of a
ContextColor array which overflows the passed in samples array.
Limiting the number of allowed samples to FZ_MAX_COLORS and make sure
to use that constant for all callers fixes the problem.

Thanks to Jean-Jamil Khalifé for reporting and investigating the issue
and providing a sample exploit file.