Minor test fixes for zlib and gzip

[rhpvorderman]

This is very minor so I did not create an issue on bugs.python.org.

I am working on a gzip-compatible library and used the tests from cpython to ensure that it was indeed compatible. I found these minor oversights when testing the library.

1. a decompressor is finished when it reaches eof. Not when it has no unconsumed tail left. The last case merely meaning it was able to consume all input, and not meaning it is finished.
2. A gzip header only stores the basename of the file. The expected name in the test used the full path. Presumably because it was a relative path with no subdirectories.

I also found test cases testing a Wbits of 32+15. Wbits sizes over 31 are undocumented in both the python and zlib documentation. Can anyone explain to me what these test cases are for, and why it is a hard requirement that these undocumented assumptions may never be broken by future python releases? I found it in the docs. It autodetects gzip or zlib style compression. That is quite a neat feature!

[taleinat]

@rhpvorderman, thanks for this PR!

The reasoning and changes suggested look good to me, but I'm not an expert on this.

I've asked @Yhg1s, listed on the experts index as the expert on zlib, to review this.

You're welcome to ping me in a few weeks if nobody else has reviewed this PR.

[rhpvorderman]

@taleinat, No reviews so far. Not that these issues are very pressing.

[taleinat]

Ping, @Yhg1s?

[erlend-aasland]

According to the devguide, this does not qualify for skip issue. IMO, this warrants an issue, despite being fairly trivial.