Remove bad GZipException and don't loop forever on 0 reads

[piksel]

PR #225 introduced a new throw that did not test the right values. The case of stream EOF is handled when attempting to fill the input buffer and inf.RemainingInput should not be used for this. Instead, the reason for the test getting stuck is that it attempts to read 0 bytes from the stream. Since the loop tries to read data until it can read at least one byte, it's forever stuck (since attempting to read 0 bytes never returns more than 0 bytes read).

The use case for supplying 0 as count is probably slim, but at least now we're not stuck in an infinite loop.

Corr for #225
Fixes #360

I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.

[piksel]

@Numpsy Any thoughts? I've been at this for some time now, but I might have missed something crucial.

[Numpsy]

I'm not sure if there are any other situations where the internal read would return 0 rather than throwing, hopefully not.