Added object stream indexing code. Seems unrelated but the set of files that we have trouble with changed. Many of the files now have issues with flatedecoder complaing of a bad header, which amy mean that somehow h_tell_m in p_take_m is not quite returning the correct location.

- Add suggestion for error reporting
- add TODO notes to self

- off by one in act_partial3group led to uninitialized memory ending up in parse result
- Check the numerical value of the resulting HBytes against A85GRPMAX in validations
- Mark printfs as debug output

- off by one error in for loop
- fix error introduced in previous commit (too many arguments to printf)

Fixed font encoding as a reference in 0000b10d35952b8723080ae52a4aa5b1871b669e6aa0762780217d489c101127

Fix segfault on dictionaries with odd lengths

See merge request !16

Fix segfault when `decode_stream` fails in xrefs

See merge request !17

Report incorrect /Filter type with decode failure

See merge request !18

It’s probably a bug that our dictionary parser is inserting a
key-value “pair” into our dictionary structure which just has a key
but no value, but the proximal cause of the crash was that `dictentry`
is reading off the end of the key-value pair and getting a null
pointer.

This fixes the bug revealed by the instigator in input file
assertion-a-used-failed.

In instigator-crashes/aux-xrefs-segfault an invalid flate-encoded stream
was producing this behavior:

    inflate: invalid distance too far back (-3)
    parse error in stream (XRef)
    ../instigator-crashes/aux-xrefs-segfault: error parsing xref section at position 249939 (0x3d053)

    Program received signal SIGSEGV, Segmentation fault.
    0x000055555555d91f in lookup_xref (aux=0x7fffffffdf60, nr=4, gen=0) at pdf.c:1249
    1249                    HCountedArray *subs = H_INDEX_SEQ(aux->xrefs[i], 0);

What was happening was that `act_ks_value`, indirectly invoked by
`parse_xrefs`, invoked `decode_stream`, which produced the "inflate:"
message and returned NULL; so `act_ks_value` produced the "parse error
in stream" message and returned an HParseResult of that NULL pointer.
Higher up the stack `act_xrstm` packs this NULL pointer into element 0
of a new `h_sequence`.  `parse_xrefs` was happily storing this
`h_sequence` into `aux->xrefs[0]`, then blithely continuing to the next
loop iteration, at which point it would report "error parsing xref
section" and return back to main().

However, this did not abort parsing the file!  main() was continuing on
to attempt to parse the PDF file as a whole, but the first time the
resulting parse tried to `lookup_xref`, that lookup would attempt to
iterate over the xrefs section in the file, checking to see if the xref
number belonged to any of them.  The line of code above then segfaulted
while attempting to assert that the NULL was actually a valid
`h_sequence` pointer.
So this patch simply prevents `parse_xrefs` from treating the failed xrefs
section as valid.  The result is that, as before, the parse exits shortly
because it can't follow any xrefs — but now without segfaulting!

    inflate: invalid distance too far back (-3)
    parse error in stream (XRef)
    ../instigator-crashes/aux-xrefs-segfault: error parsing xref section at position 255242 (0x3e50a)
    VIOLATION[1]@433 (0x1b1): Missing endobj token (severity=1)
    ../instigator-crashes/aux-xrefs-segfault: no parse
    VIOLATION[1]@433 (0x1b1): Missing endobj token (severity=1)
    ../instigator-crashes/aux-xrefs-segfault: error after position 433 (0x1b1)
    [Inferior 1 (process 626584) exited with code 01]