Use actual `async fn` for traits

[deifactor]

(First: thanks a ton for the crate, I'm using it in my music player and it's nice not having to think about this stuff myself :) )

Now that async fn in traits has landed in stable Rust, I think it's possible to have the FooInterface traits use that instead of async_trait. If you're fine with an MSRV bump, then this is easy, but if you want to gate them behind a feature flag it gets trickier; features aren't supposed to introduce incompatible changes, so the simple answer of "add a native_async_trait feature that swaps them" doesn't work. You could have a macro_async_trait and native_async_trait features that are incompatible (with the first one enabled by default), or move the "native" ones into a separate submodule. I'm happy to do the actual implementation grunt work, but it's your library so I wanted to leave the design up to you.

[SeaDve]

I'm absolutely fine with bumping the MSRV. Simplicity, in my opinion, would take precedence because the library is still on 0.X.X; we don't need to overcomplicate things.

I attempted to port it to AFIT a few days ago but it doesn't work yet, and it is more of a branch experimenting on how AFIT works, so feel free to create a merge request if you want to.

One problem I had is handling the local and non-local variants of the traits. I tried trait_variant crate, but it doesn't forward the docs, so we might want to retain the current implementation.

[SeaDve]

One problem I had is handling the local and non-local variants of the traits. I tried trait_variant crate, but it doesn't forward the docs, so we might want to retain the current implementation.

Oh, It seems I was wrong, it actually forwards the docs, but not sure how to specialize it (i.e., mention that this is the "local" variant)

[SeaDve]

If you're still interested, please test #7, thankss

[deifactor]

Works fine; haven't tested the Local variant though.