LibPDF: Improve stream parsing

When parsing streams we rely on a /Length item being defined in the
stream's dictionary to know how much data comprises the stream. Its
value is usually a direct value, but it can be indirect. There was
however a contradiction in the code: the condition that allowed it to
read and use the /Length value required it to be a direct value, but the
actual code using the value would have worked with indirect ones. This
meant that indirect /Length values triggered the fallback, "manual"
stream parsing code.

On the other hand, this latter code was also buggy, because it relied on
the "endstream" keyword to appear on a separate line, which isn't always
the case.

This commit both fixes the bug in the manual stream parsing scenario,
while also allowing for indirect /Length values to be used to parse
streams more directly and avoid the manual approach. The main caveat to
this second change is that for a brief period of time the Document is
not able to resolve references (i.e., before the xref table itself is
not parsed). Any parsing happening before that (e..g, the linearization
dictionary) must therefore use the manual stream parsing approach.

Userland/Libraries/LibPDF/DocumentParser.h

@@ -25,6 +25,8 @@ public:
     // Parses the header and initializes the xref table and trailer
     PDFErrorOr<void> initialize();
 
+    bool can_resolve_references() { return m_xref_table; };
+
     PDFErrorOr<Value> parse_object_with_index(u32 index);
 
     // Specialized version of parse_dict which aborts early if the dict being parsed