Add support for async readers #68
Description
When loading from a reader using e.g. load_obj_buf, the reader object it takes is synchronous. In an async context with async readers, this means you either have to asynchronously read the entire input into memory and then pass the in-memory buffer to load_obj_buf, or wrap the async reader in a sync wrapper, which will cause the async context to block while reading the input (negating the point of async entirely). Neither is really good.
load_obj_buf_async does exist, but it only partially solves the problem, in that it allows the material loader hook to be async, but doesn't allow you to use async readers. It effectively enables you to use one of the two workarounds mentioned above.
Is it reasonable to add an additional API that supports being given async readers? I believe this is the only line that needs to change to use an async reader, so with some clever refactoring into some common functions, the vast majority of the loading code can be reused.
Unfortunately, however, there are no standardized async read/write traits, and the big key frameworks tend to use their own versions. In order to deal with this, I propose adding framework-specific support gated behind new feature flags. For example, to use smol/async-std, the new API would have to take a futures AsyncRead. This can be enabled by adding a futures feature flag, and adding a futures-specific API to run with it. Something similar could also be done for Tokio's AsyncRead.
If this is acceptable, I don't mind creating a pull request myself.
Also, if I'm just blind and somehow missed existing support for async readers, feel free to point me to it.