Support for other runtimes

[SirAlador]

Support other runtimes by:

• Changing all instances of tokio::io::{AsyncRead, AsyncWrite, AsyncSeek} and their extensions to those found inside the futures crate
• Moving from the tokio feature to the futures-io feature of async_compression
• Creating a submodule tokio that mirrors the main API, but using tokio_utils::compat::Compat to operate on Tokio's types instead
  • The fs module would be exclusive to this tokio module
  • Caveat: Compat does not provide an implementation of AsyncSeek. A small newtype wrapper implementing AsyncSeek could be included in this crate for internal use. Smol's async-compat provides an implementation, but it also tampers with tokio's runtime, so it might not be the best idea.
• Gate the tokio module behind a feature flag, perhaps enabled by default
• Applying the same changes to your sister crate async_io_utilities

I'll be modifying the crate for use with my project that uses async-std, so if this is something you're interested in, I'd be happy to polish the API and submit a PR.

[Majored]

This is something I'd be interested in but wasn't going to personally tackle until way down the line (ie. I'm focusing on spec compliance primarily). So a PR for this would be very handy & welcomed. 👍

[bancek]

I've forked this repo (it looks like just a few days before #82) to add support for futures-rs without tokio for generating streaming ZIP files in WASM (only writing as I didn't need async reading).

We are using this in Koofr Vault.

[Majored]

Thanks to @jakubadamw and the suggestions in https://github.com/Majored/rs-async-zip/issues/89, this has been implemented.

The base implementation now revolves around futures' IO types & compatibility constructors/type aliases are provided in the tokio module in an attempt to make the switch as seamless as possible.

I'll go ahead and close this as a result. 👍