Includes a failing test. The decoder currently mishandles the code word
following a clear code. It expects a literal (codes 0-255) but accepts
the range 0-257. This appears to be the root cause of issues #26 and #37.

While we generate an error message in parse_xrefs() for this case, parse_xrefs
is not the right place to cause the parse error. That should be a semantic
validation in the parser proper. Other checks in parse_xrefs can probably be
moved completely out of the function in that vein, too.

But we will leave doing that properly for another time. For now, let's put a
comment to the effect in parse_xrefs and disable the failing test case by
masking its .pdf extension.

If a .txt file is found next to a given PDF in the "valid" set, take it
as expected text output. Run text extraction on the PDF, saving the
result with extension .txt.out and diff it to the .txt.

Includes a test case for hello.pdf which fails because that file uses a
plain reference for /Contents and we only handle the case where
/Contents is an array.

Includes a second test case hello1.pdf which uses a one-element array
for /Contents but also fails because the code spews diagnostic output to
stdout.

Not that it's terribly important, but if we distinguish in the exit code
whether "valid" or "invalid" tests failed, let's do it right and not blindly
override one result with the other.

Now, each section gets to set one bit in the result if one of its tests failed.

Nothing much to say, cosmetic change. Makes the test successes look a bit
more muted compared to the failures.

This commit contains a failing test case. It contains a stream with a
/Type entry that is an indirect reference to an object defined as
itself:

    obj 8 0
    8 0 R
    endobj

The implementation of resolve() does not properly detect cycles and runs
into an infinite loop.