OpenSystemsDevelopment / qpdf

* Return rather than exiting from realmain in qpdf.cc
* Remove extraneous blank line
* Don't assign temporary to const reference

The jpeg library has some assembly code that is missed by the compiler
instrumentation used by memory sanitization. There is a runtime
environment variable that is used to work around this issue.

Specifically, if a stream had its stream data replaced and had
indirect /Filter or /DecodeParms, it would result in non-silent loss
of data and/or internal error.

There isn't really an issue with these files causing a real problem,
but malware and virus checkers trip on them, and the value to leaving
them in the test suite is too low to be worth the hassle.

Wildcard expansion is different in Windows from non-Windows and
sometimes requires special link options to work. Add tests that fail
if we link incorrectly.

This is suitable for use as a Lambda layer in AWS, inclusion in a
docker container, or other places where a minimal binary distribution
is desired.

Fixes a crash found by fuzzing.

OPENSSL_IS_BORINGSSL is not actually set by configure, so it will be
undefined until a BoringSSL header is included.  Hence the #ifdef logic
in QPDFCrypto_openssl.h would usually never apply.

This still worked because evp.h transitively included BoringSSL's
cipher.h and digest.h, but the latter are the correct (documented)
headers.

By re-ordering the includes, we can ensure the macro is defined when we
use it.

Also: fix case in the header guards.

- Checks explicitly for versions >= 1.1.0 with pkg-config
- Refactor the fallback checks.  Previously they were copied
from the gnutls logic, but could be slightly surprising (it's not
obvious that they're for the case where pkg-config returns a false
negative, and it's weird that the linker check overode the header check)
- Fix the AC_SEARCH_LIBS check to try -lcrypto instead of -lopenssl
(-lcrypto is the standard library OpenSSL ships the crypto symbols in).
- Fix the AC_SEARCH_LIBS check to look for EVP_MD_CTX_new, which is not
present in versions prior to 1.1.0.

Fixes qpdf/qpdf#429 (although I haven't verified on cygwin)

Fixes qpdf/qpdf#450

On large files with predominantly \n line endings, memchr(..'\r'..)
seems to waste a considerable amount of time searching for a line
ending candidate that we don't need.

On the Adobe PDF Reference Manual 1.7, this commit is 8x faster at
QPDF::processMemoryFile().

This is all that ever worked. The test suite was trying to do
something different from ClosedFileInputSource.