[ruby/zlib] In Zlib::GzipReader#eof? check if we're actually at eof

	Only consider it eof if we read ahead and something fills the buf.
	If not, we may only have empty blocks and the footer.

	Fixes https://github.com/ruby/zlib/pull/56

	https://github.com/ruby/zlib/commit/437bea8003

https://github.com/ruby/zlib/commit/2561e122ac

https://github.com/ruby/zlib/commit/661ea3ec5f

extconf.rb
(https://github.com/ruby/zlib/pull/69)

The android NDK (android-ndk-r21e) does not have crc32_z, adler32_z, nor
z_size_t in its zlib.h header file. However, it _does_ have the crc32_z
and adler32_z symbols in the libz.a static library!

mkmf performs two tests for have_func:
* It sees if a program that includes the header and takes the address of
  the symbol can compile
* It sees if a program that defines the symbol as `extern void sym_name()`
  and calls it can be linked

If either test works, it considers the function present. The
android-ndk-r21e is passing the second test but not the first for
crc32_z/adler32_z. So, we define HAVE_ZLIB_SIZE_T_FUNCS, but then can't
actually compile the extension (since the prototypes aren't in the
header file).

We can keep this working how it was working before by _also_ checking
for `have_type("z_size_t", "zlib.h")`. The have_type check _only_ looks
in the header file for the type; if a program including the header file
and using the type can't compile, the type is considered absent
regardless of what might be in libz.a.

https://github.com/ruby/zlib/commit/3b9fe962d8

We use the Cloudflare fork of zlib
(https://github.com/cloudflare/zlib), which we find gives improved
performance on AWS Graviton ARM instances. That fork does not define
crc32_z and alder32_z functions.

Until two days ago, Ruby's zlib gem worked fine, because cloudflare zlib
_also_ did not define z_size_t, which meant Ruby did not try and use
these functions.

Since https://github.com/cloudflare/zlib/commit/a3ba99596d6271224d39ef9d6853511f51821e05
however, cloudflare zlib _does_ define z_size_t (but NOT crc32_z or
alder32_z). The zlib gem would try and use these nonexistant
functions and not compile.

This patch fixes it by actually specifically detecting the functions
that the gem wants to call, rather than just the presence of the
z_size_t type.

https://github.com/ruby/zlib/commit/c96e8b9a57

(https://github.com/ruby/zlib/pull/55)

zstream_discard_input was encoding and character-aware when given input is user-provided, so this discards `len` chars instead of `len` bytes.

Also Zlib.gunzip explains in its rdoc that it is equivalent with the following code, but this doesn't fail for UTF-8 String.

```ruby
string = %w[1f8b0800c28000000003cb48cdc9c9070086a6103605000000].pack("H*").force_encoding('UTF-8')
sio = StringIO.new(string)
p gz.read #=> "hello"
gz&.close
p Zlib.gunzip(string) #=> Zlib::DataError
```

Reported and discovered by eagletmt at https://twitter.com/eagletmt/status/1689692467929694209

https://github.com/ruby/zlib/commit/c5e58bc62a