Correctly instrument fns returning an async move block

[Swatinem]

This should take care of half of #1863, meaning it should instrument functions returning an unboxed async move block.

This unfortunately does not cover generic impl Future returns, such as std::future::ready() and similar :-(

[hawkw]

Oops, I left a review on the your draft PR (#1865): #1865 (review)

I was expecting that the draft PR would be marked as ready for review, rather than opening a new PR...sorry about that!

[hawkw]

Ah, I see that the main difference between this PR and #1865 is that #1865 also adds tests. Personally, I would prefer to also merge the tests, rather than removing them --- it would be nice to have tests that catch regressions in the future. Can we add the tests to this PR (or mark #1865 as "ready for review" instead?)

[Swatinem]

Ah yes, sorry.
I meant to split that up into smaller incremental changes. The larger issue (the call not being instrumented) is still not solved, but I started with a failing testcase to understand how things work.

So this here (support for manual async blocks) works and can land already.

Learning how the matching and code generation works, I think I have an idea how to solve my other problems as well.

[hawkw]

This looks good to me, thanks for the docs changes!

If you'd prefer, I'm fine with merging this PR now, and making the additional change to enter the span for the duration of calling the function in a separate PR? I have some thoughts about how we could do that, if you're interested, but if you've already figured it out, that's great too!

One other note: I don't believe this will work correctly for code where a different impl Future is returned in one of multiple branches, such as

#[instrument] 
fn probably_doesnt_work(which_fut: bool) -> Pin<Box<dyn Future<Output = ()>>> {
    if which_fut {
        Box::pin(async move { /* ... */ })
    } else {
        Box::pin(async move { /* ... */ })
    }
}

it might be nice to handle that case, as well, in a follow-up PR, but the implementation might be significantly more complex. We could probably do that transformation using syn's Fold API.