OpenSystemsDevelopment / qpdf

These mean to leave the original values alone. This is needed for
reconstructing streams from JSON given that the stream data and stream
dictionary may appear in any order in the JSON.

I decided these were confusing and inconsistent with how JSON works.
They muddle the API rather than improving it.

This reverts commit dc059560e73e0b373a6e54e71b07e3af4b692cb4.

I changed my mind. There's no harm in leaving it deprecated for a
release cycle.

See ChangeLog for rationale for not deprecating it as originally
planned.

The PDF spec only allows UTF-16BE, but most readers seem to accept
UTF-16LE as well, so now qpdf does too.

This was unintended behavior that was added back for backward
compatibility. It is intentionally undocumented.

There are codepoints in PDFDoc that are not valid UTF-8 but map to
valid UTF-8. We were handling those correctly with bidirectional
mapping.

However, if those same code points appeared in UTF-8, where they have
no meaning, they were left as fixed points when converting to PDFDoc,
where they do have meaning. This change recognizes them as errors.