Async GzDecoder

[quininer]

This PR implements async gzip header parsing. It will fixed #179 .

• It changed some behavior of GzDecoder and was a breaking change.

[alexcrichton]

Thanks for the PR! I've done a quick skim over this and was wondering if a few high-level points could be knocked out before doing a deeper review:

• Instead of having an enum of states we cycle between, could we just buffer data internally until the whole header has been read? In theory the header is quite small and won't take long, even over async connections, to wait for it to all arrive.
• Could the new2 functions be avoided? Ideally this doesn't affect the public API, only adding a few trait impls as necessary to publicly exposed types.

[quininer]

• I have tried to use BufRead instead of a state machine for parsing, but GzWriter doesn't provide BufRead for this, so I switched to a state machine instead. If you prefer BufRead, I am willing to make changes.
• In an async context, we usually don't want to consume read before polled. This caused us to not get the header immediately, which is a breaking change.

[alexcrichton]

Right yeah I don't think we need to deal with BufRead, just read data into a local buffer until the full header is available and then we parse it all in one go.

I'm not sure I understand your comments about new2 though, can you clarify?

[quininer]

I may have thought wrong before. :(

[quininer]

ping? @alexcrichton

[alexcrichton]

Oh oops sorry for the delay!

[alexcrichton]

Ok looks good to me, thanks!

[quininer]

Can you release a new version for it?

[alexcrichton]

Published!