[BUG] ZipDataSource mempty compresses to invalid zip files; add test

[ulidtko]

Hi again @dylex!

When using the compression part of the library in production, we stumbled over a corner-case. Turns out, if archive member data is provided through a conduit (via ZipDataSource), and that conduit never yields — the output zip archive is... I don't want to say "corrupted" (ubuntu's unzip still partially extracts it — but not all decompressors do, including the one in this library) — let's say, definitely "not entirely valid".

Please try the added test. It fails unexpectedly, and you can check the produced output. Infozip's unzip says invalid compressed data to inflate on it:

$ unzip /tmp/test.zip
Archive:  /tmp/test.zip
  inflating: roses.txt               
 extracting: empty_OK_1.txt          
  inflating: empty_OK_2.txt          
  inflating: empty_BUG.txt           
  error:  invalid compressed data to inflate
  inflating: trailer.txt

I looked at it, and attempted a fix — but it didn't help, I don't quite understand why.

(I also don't understand why empty_OK_2.txt has compressed length 2, and not 0).

In practice, this wasn't a major issue for us — as there's an easy workaround, of wrapping all ZipDataSource arguments in a little (yield "" >>) in user-code relative to zip-stream. But I just thought, as a FOSS courtesy, you would better be made aware. Perhaps you can think of a fix for this that will improve the library.

By all means, feel free to discard this PR, or merge after some reworks — it's really only a bug report, with a patch attached to demonstrate the issue that's quite specific.