feat(neon): Add tokio async runtime support

[kjvalencik]

This PR adds support for exporting async fn and future return fn in #[neon::export].

#[neon::export]
async fn example1(a: f64, b: f64) -> f64 {
    a + b
}

#[neon::export(async)]
fn example2(a: f64, b: f64) -> impl Future<Output = f64> {
    async move {
        a + b
    }
}

It is intentionally very conservative in semver guarantees. It requires registering a global future executor. The executor must implement the private Runtime trait. Currently, only a tokio implementation is included. Additionally, Future trait bounds are strict enough to allow for multi-threaded executors.

As we see demand, we can add support for additional executors (e.g., async-std) and possibly even single threaded executors (#[neon::export(?Sync)]) or a built-in libuv driven executor. The eventual goal is to make the Runtime trait public so that users can bring their own executor.

• Depends on improve(neon): Use autoref specialization for JSON wrapping return values in exported functions #1057 (Merged)

[kjvalencik]

@dherman This doesn't need the unused _cx, but I was trying to show that it can use a cx. A few options:

• Leave it as is
• Switch to console.log to demonstrate using it
• Remove it
• Comment it out to show that it could be used but isn't required

Suggested change

	/// fn add(_cx: &mut FunctionContext, a: f64, b: f64) -> NeonResult<impl Future<Output = f64>> {
	/// fn add(/* cx: &mut FunctionContext, */ a: f64, b: f64) -> NeonResult<impl Future<Output = f64>> {

What do you think?

Similarly, NeonResult isn't used here. Originally it was because I planned on calling console.log, but then I left it in. I think maybe it should be removed? Let me know, I was trying not to have 100 different examples.

[dherman]

Honestly I feel like we should have a shorthand for the console, so you could do:

cx.console()?.log(&mut cx, "Hello from the main JavaScript thread!")?;

But for now why don't we just remove the cx argument entirely and the NeonResult, and we can add it back after we merge #1056, because then we could at least write:

    cx.global("console")?
        .get(&mut cx, "log")?
        .bind(&mut cx)
        .arg("Hello from the main JavaScript thread!")
        .apply()?;

[dherman]

Actually I think it's probably best to leave them out for good. The docs don't talk about taking a FunctionContext until the bottom of the page, so it's best not to jump ahead. IMO we should keep it simple with println! for these examples.

[dherman]

A few small changes, but nothing major. TBH I'm a little worried my lack of expertise at tokio and async means my review might be a little superficial. But the API is so easy to understand and fits so nicely with the #[export] macro syntax. This is a really exciting addition.

[dherman]

Actually I think it's probably best to leave them out for good. The docs don't talk about taking a FunctionContext until the bottom of the page, so it's best not to jump ahead. IMO we should keep it simple with println! for these examples.