* john/erts/fix-gunzip-eos/OTP-14730/ERL-507:
  Only apply EOS behaviors if there's pending data

The docs for zlib:deflateInit/6 explicitly mention that 8 is broken
and should not be used unless we know for certain that our zlib
version supports it.

1.2.11 started bailing when avail_out==0 regardless of whether
there's anything to flush or not, and there's no point in adapting
the old method since it was vulnerable to bugs in other zlib
versions which updated the deflate parameters even on failure.

The api_deflateParams test has been expanded accordingly, and two
white-box cases in zip_usage has been updated to make fewer
assumptions about the output; the validity of the compressed data
is what matters, not whether it's exactly the same as the test
vector.

Quoting RFC 1952:

"A gzip file consists of a series of "members" (compressed data
sets). [...] The members simply appear one after another in the
file, with no additional information before, between, or after
them."

When presented with multiple valid but concatenated streams, the
old driver returned an empty result once the end of the first
stream was reached, and kept doing so even if fed new data. The
new driver/NIF returned a data_error instead.

zlib:inflateInit/3 has been added to control this behavior, but is
not yet ready for public use.

~tw and new string functions are new since OTP-20 (stdlib-3.4)