Lower `async fn` and `impl Future` as a thunk, since Rust's futures are lazy

`async fn f() -> T` is `fn f() -> impl Future<Output = T>` -- Rust's own
desugaring -- so async and return-position `impl Future` are one feature.

The mapping that suggests itself, `async fn` onto Nim's `{.async.}`, is wrong
and measurably so. A Rust future is inert: calling an async fn runs none of
its body until something polls it. A Nim `{.async.}` proc runs eagerly, up to
its first await, at the moment it is called. Probed side by side on the same
program, rustc prints "before call / after call / body ran" where Nim prints
"before call / body ran / after call". Every side effect ahead of the first
await would move.

So a future is a thunk: RsFuture[T] = proc (): Future[T]. Calling the
function builds one and runs nothing; `.await` calls it. That restores Rust's
order exactly. tests/cases/042-async.rs pins it against the real futures
crate -- oracle-only, as with bitflags and log -- and includes a future that
is built and never awaited, whose body must not run.

The async runtime is emitted only when the input needs it, since importing
std/asyncdispatch costs compile time and most programs have no futures. A
captured openArray gets the same copy as a returned iterator, for the same
reason: Nim will not let a closure capture a view.

Not modelled and rejected where they appear: cancellation, Pin, Send/Sync
bounds, and the choice of executor -- Nim has one global dispatcher where
Rust's runtime is the application's choice, so block_on from any executor is
the same operation here.

Async blockers in the 400-crate survey: 15 to 1. Accepted crates unchanged at
18, Nim-compilable at 12. Eleventh feature with that result.

48 differential cases, all green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>