Replace cap-async-std

[0xIO32]

cap-async-std has been removed without a replacement (see #399), because async-std is no longer maintained.
Now there is no way of using async code with this crate.

It would make sense to add either a:

• cap-tokio (I would prefer this one)

or a

• cap-smol

crate to this repository to retain the async functionality of this project.

[sunfishcode]

Either of those would indeed be nice to do. I myself don't have the bandwidth to do them, however.

[Ericson2314]

I just started trying to slop cap-tokio into being.

[cgwalters]

Personally, I think it's simpler and actually more efficient in some ways to just encapsulate high level cap-std workflows (i.e. more than one operation) into a tokio spawn_blocking thread.

[ssokolow]

To be honest, I'm preparing to either borrow code from #414 for my project or vendor a copy of tokio::fs::read_dir where I swap out the wrapped std::fs::read_dir operations for cap_std::fs::Dir::read_dir ones.

If for no other reason, because I tend to work with folders large enough that being able to cleanly abort retrieving a list of contents is valuable and Tokio already figured out the DOs and DON'Ts of incorporating read_dir into it.

I hope this won't be another case of "The image crate closed my request, so now I have to vendor a copy of their code because what I want is literally their glue code that can't be meaningfully written any other way, but with a means to use the APIs provided by the underlying png crate to inject some XDG Thumbnailing Spec metadata in the process".