OpenSystemsDevelopment / qpdf

Commit by ejb@ql.org using m-holger as author so git annotate gives
proper credit for changes.

Add methods isNameAndEquals, isDictionaryOfType, isStreamOfType

They have to be ot_* rather than qpdf_ot_* for compatibility.

* Different enumerated types are not assignment-compatible in C++, at
  least with strict compiler settings
* While you can do `constexpr ot_xyz = ::qpdf_ot_xyz` in QPDFObject.hh to
  make QPDFObject::ot_xyz work, QPDFObject::object_type_e::ot_xyz will
  only work if the enumerated type names are the same.

* Make it a runtime error, not a logic error
* Include additional information
* Capture it properly in checkLinearization

* Handle error conditions that occur when using the object handle
  interfaces. In the past, some exceptions were not correctly
  converted to errors or warnings.
* Add more detailed information to qpdf-c.h
* Make it possible to work more explicitly with uninitialized objects

It was exercised in the pdf-linearize example but not in qpdf-ctest.

Return new qpdf_oh from qpdf_oh_wrap_in_array when input is already an array.
Update some doc comments in qpdf-c.h.

Don't assume endobj is at the beginning of the line. This means we are
looking at tokens for every line, but the odds of n n obj appearing in
the middle of the object are likely much lower than endobj not being
at the beginning of the line or missing entirely. This will probably
have a negative impact on recovery time for very large files.
Hopefully it will be worth it.

When making resources indirect in from_dr, the code was using the
wrong owning QPDF, forgetting that from_dr had already been copied
using CopyForeignObject.

When adding a QPDFObjectHandle to an array or dictionary, if possible,
check if the new object belongs to the same QPDF. This makes it much
easier to find incorrect code than waiting for the situation to be
detected when the file is written.

This was originally not public because I wanted to get rid fo the
pages cache, but I recently realized there were deep reasons not to do
that, and the author of pikepdf wanted this, so I decided to make it
public.

The /Subtype entry that specifies the mime type of an embedded file is
inside the embedded file stream dictionary directly, not it in the
parameter dictionary.

See Table 45 and 46 in the PDF 1.7 specification:
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#page=112

Check for this->encrypt seems to be moved to plugged crypto
implementations, so it can be removed from Pl_AES_PDF.cc.