Warn for PDF's with compression + unsup'd filters

As described in issue #1721, some PDF's will crash FontForge due to the
use of added filters in combination with object stream compression.

In the example crash, FlateDecode compression was combined with PNG value
filtering,
>   /Filter /FlateDecode
>   <</DecodeParms<</Columns 5/Predictor 12>>

FontForge did not look for nor handle the /DecodeParms value for any
objects.  This basically meant that the object stream was corrupted
and unguarded code used the resulting bad values causing the crash.

Filter implementation would require adding a step after decompression
to un-filter the stream.  There are a number of known filters.  (see
PDF version 1.7 document section 3.3 "Filters" for more details)

As implementation would take time and sample PDF files not available
at present, for now just warn the user that this PDF file contains
features not supported and don't use the file (preventing crash).

The warning as seen from the UI, in "Warnings" popup:
> Unsupported decode filter parameters : <</Columns 5/Predictor 12>>

There may be other warning/error messages, depending on what data part
of the PDF file is found to have this unsupported combination.

Note that this change's check for the problem situation is rather
superficial.  FontForge can be forced to handle subdictionary values
but it is very painful.  Better would be to completely unpack the
/DecodeParms subdictionary and verify that the Predictor value is
not '1'. As it is we only check if /DecodeParms is present and then
give up and warn.
parsepdf.c FindXref() small bug finding startxref

While examining code in parsepdf.c I was confused by code in routine
FindXref() that locates the section in a PDF file that points to the
start of the tables in a PDF. Checking more closely and comparing with
the previous version of the routine, I realized it could be tripped up
by slightly malformed trailers, e.g.
>     endobj
>     sstartxref
>     2250179
>     %%EOF

At first I reworked the code, fusing new code with old to correct the
glitch. But then I realized the code using loops was confusing without
needing to be in order to work.  Replaced loops with straightforward
reading of needed algorithm.

Tested with both good and multiple constructed 'bad' PDF file trailers.

This problem has not actually been demonstrated to my knowledge.
Hitting the bug would have produced messages like:
> Doesn't look like a valid pdf file, couldn't find xref section
> Couldn't find a font file named /home/tom/study/fonts/FF/gdb.pdf.test.3.pdf
> gdb.pdf.test.3.pdf is not in a known format (or uses features of that format fontforge does not support, or is so badly corrupted as to be unreadable)
Merge pull request #1727 from tshinnic/parsepdf_bugs_1

Fix crash in parsepdf.c on filter&compression; fix another minor nit