OpenSystemsDevelopment / qpdf

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.

I don't need qpdf's fuzz to find leaks and invalid memory in gnutls.

Thanks to Zdenek Dohnal <zdohnal@redhat.com> for contributing the code
used for the gnutls crypto provider.

Just rename MD5 -> MD5_native in place so that git annotate will show
the lines as having originated there.

Since g++ (as of this writing) uses c++14 by default, this prevents me
from accidentally using c++14 features.

Includes updates to m4/ax_cxx_compile_stdcxx.m4 to make it work with
msvc, which supports C++-11 with no flags but doesn't set __cplusplus
to a recent value.

Removed ones that were fixed upstream, and added a new one, all from
the jpeg library.

Various PDF digital signing tools do not encrypt /Contents value in
signature dictionary. Adobe Acrobat Reader DC can handle a PDF with
the /Contents value not encrypted.

Write Contents in signature dictionary without encryption

Tests ensure that string /Contents are not handled specially when not
found in sig dicts.

It seems better not to compress signature dictionaries. Various PDF
digital signing tools, including Adobe Acrobat Reader DC, do not
compress signature dictionaries.

Table 8.93 "Entries in a signature dictionary" in PDF 1.5 reference
describes that /ByteRange in the signature dictionary shall be used to
describe a digest that does not include the signature value
(/Contents) itself.

The byte ranges cannot be determined if the dictionary is compressed.

Table 8.93 "Entries in a signature dictionary" in PDF 1.5 reference
describes that the value of Contents entry is a hexadecimal string
representation when ByteRange is specified.

This commit makes QPDF always uses hexadecimal strings representation
instead of literal strings for it.