OpenSystemsDevelopment / qpdf

When possible, use `for (auto&` or `for (auto const&` when iterating
using C++-11 style iterators.

Build fails on gcc 4.8 since version 9.1.1 and commit
752416554086d5d34323bc14164d5084db83cfbd:

libtests/cxx11.cc: In function 'void do_regex()':
libtests/cxx11.cc:347:42: error: 'strlen' is not a member of 'std'
     std::cregex_iterator m3(str7, str7 + std::strlen(str7), expr4);
                                          ^

To fix the build failure, add missing include on cstring

Fixes:
 - http://autobuild.buildroot.org/results/ad7fb68ae87850a85509eed80fd0cae8721b10c5

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

This commit adds the preserve_eol flags but doesn't implement EOL
preservation yet.

If QPDF_CRYPTO_PROVIDER is set, just run the tests for the given
provider. This is to support cases of running the entire test suite
for each provider. If QPDF_CRYPTO_PROVIDER is not set, run the tests
that exercise the cyrpto provider for each available provider.

This code was essentially duplicated between test_driver and
standalone_fuzz_target_runner.

Have classes contain only a single private member of type
PointerHolder<Members>. This makes it safe to change the structure of
the Members class without breaking binary compatibility. Many of the
classes already follow this pattern quite successfully. This brings in
the rest of the class that are part of the public API.

This makes all integer type conversions that have potential data loss
explicit with calls that do range checks and raise an exception. After
this commit, qpdf builds with no warnings when -Wsign-conversion
-Wconversion is used with gcc or clang or when -W3 -Wd4800 is used
with MSVC. This significantly reduces the likelihood of potential
crashes from bogus integer values.

There are some parts of the code that take int when they should take
size_t or an offset. Such places would make qpdf not support files
with more than 2^31 of something that usually wouldn't be so large. In
the event that such a file shows up and is valid, at least qpdf would
raise an error in the right spot so the issue could be legitimately
addressed rather than failing in some weird way because of a silent
overflow condition.

JSON serialization was preserving the value as presented, but JSON
doesn't accept decimal values without a 0 before the decimal point.

Support conversion of pages to form XObjects and placement of form
XObjects on pages.

Unparse is admittedly strange, but I'd rather be strange and
consistent, and everything else in the qpdf library uses unparse to
serialize. (If you're reading this, the convention of using "unparse"
comes from the "clu" programming language.)

Also move tests to libtests.