Implementing support for async_std types

[gabrik]

This PR contains the code for supporting async_std types in MmapOptions.

The async_std support is gated using a feature.
If someone wants to use this feature has to enable it in their Cargo.toml

eg.

memmap2 = {version = "0.3.1", features = ["async"] }

I tested it on this crate: https://github.com/atolab/zenoh-cdn/tree/feat/all-async

I had no possibility yet to test it on a Windows machine

[RazrFalcon]

Can you also write tests? I guess they should be implemented as a separate crate or example or something. I'm not familiar with async at all.

[gabrik]

This was added to avoid testing the documentation examples.
When testing the async feature the documentation examples fail, this is why I disabled it.

[RazrFalcon]

CI fails.

[adamreichold]

Is it really necessary to special case this for the types from async_std? Can't this be achieved by going through raw file descriptors resp. handles without direct coupling between the crates?

Related to that, the use of the feature does seem problematic, e.g.

#[cfg(feature = "async")]
#[cfg(windows)]
pub struct MmapRawDescriptor(async_std::os::windows::io::RawHandle);

#[cfg(not(feature = "async"))]
#[cfg(windows)]
pub struct MmapRawDescriptor<'a>(&'a File);

seems to imply that if any crate in the dependency tree enables the async feature, this crate will loose its support for std::fs::File? What if there are users of this crate which depend on the std-based API? Features should generally be additive, i.e. in this case add implementations of MmapAsRawDesc but not remove them.

[RazrFalcon]

Agree. I would prefer the integration of this feature to be more simple.

[RazrFalcon]

Superseded by #31