gzip: Correctly handle multiple members

[wader]

A gzip file consists of one or more "members" that are concatenated on uncompress.

Introduce a members array with each member and uncompressed is now the concatenation.

Fixes #794

[TomiBelan]

Looks good.
But double check the testdata. Some files got suspiciously shorter. format/text/testdata looks bad. And I don't see why this PR affects format/zip/testdata.

[TomiBelan]

Are you sure the other testdata changes are ok?

In format/gzip/testdata/compressed_size.fqtest and format/json/testdata/tofromjson.fqtest, is it intentional that the test doesn't show what's inside the gzip anymore?

In format/zip/testdata/test0.fqtest etc, why does the local_files entry for test/ (a directory, whose content is an empty string) change from uncompressed: raw bits 0x3f-0x3f (0) to uncompressed[0:1]: (gzip) 0x3f-0x3f (0)?

[wader]

Are you sure the other testdata changes are ok?

Nope :) I thought so but i was a bit too quick, fixed. Thanks! some weirdness in the output i think was caused by that the gzip decoder succeeded for an empty input.

Now i've remodelled so that the root is a struct again and then there is a "members" array and the root "uncompressed" is the concat of the member uncompressed. You can still access each member uncompress as .members[].uncompress

What do you think? i'm still not very happy with the uncompress related code in fq, is a bit of a mess, but have not found good abstraction yet to make it more shareable between compression formats.

[TomiBelan]

I haven't reviewed the go code, but the output looks good. 👍

[wader]

Ok, thanks! i'm still not very happy with the most of the archive decoders in fq but that is for a future PR. Ex user facing-wise it would be nice if all of them had common uncompress and decode_uncompressed/files etc.