Re-export task::spawn and task::spawn_blocking at top-level

[joshtriplett]

These are fundamental operations that crates will use constantly; make
it possible to write async_std::spawn or async_std::spawn_blocking
to make examples and tests easier to write without requiring as many
use lines.

This PR depends on #1017 so that it
can re-export both.

[joshtriplett]

Now passes CI other than the unrelated failure fixed by #1019 .

[yoshuawuyts]

A goal we had when designing async-std was to create a module hierarchy which resembled the hierarchy of the stdlib - but expanding on it with async-only capabilities in certain locations. This was with the expectation that one day we might add these APIs into the stdlib itself. And at least my hope is that we may eventually enable a diff like this:

- use async_std::task::spawn;
+ use std::task::spawn;

You're probably in a better position to answer this, but I kind of assumed that in the stdlib we would likely want to scope the spawn family of functions to submodules, and likely not expose them directly from std's root? Meaning that even if we create an async_std::spawn, we'd unlikely ever have a std::spawn?

Alternatives

I do think you're touching on an important insight here though: spawning tasks is a common operation, and making that convenient to perform seems important. I've recently been experimenting with making spawn a method on Future. This solves the same problem by not requiring any imports at all:

use tasky::prelude::*;
 
async_std::task::block_on(async {
    let res = async { "nori is a horse" }
        .spawn()               // <- `FutureExt::spawn`
        .name("meow".into())
        .await;
    assert_eq!(res, "nori is a horse");
})

Open questions
I've been contemplating whether we could add this to async-std as part of FutureExt, possibly even deprecating task::spawn as part of it. Though there are still a few open questions with this:

1. The path for inclusion in the stdlib seems less clear. The base trait lives in core::future::Future, but this extension may only be possible on std? Perhaps there is something with contexts we could provide, or perhaps the unification of core and std would help? But I'm not sure what the right path for the stdlib here would be.
2. The tasky prototype of this idea has both spawn and spawn_local variants of this method. This is probably worth its own blog post, but spawn_local doesn't appear to be the right abstraction. Instead we need to find a way to define a spawn method with "the captured values from the scope can be sent to another thread, but once the future is constructed it will no longer move between threads". Much like the thread::spawn API works. I'm not sure yet how to do this, as it seems like it needs to be implemented at the async-task layer.
3. I'm not sure what to do about spawn_blocking. It doesn't really make sense to define it as FutureExt::spawn_blocking since it's only intended to be used for non-future workloads. Having a T::spawn_blocking feels wrong too. How common is it to use this method? What is the right way to expose this functionality?

[joshtriplett]

You're right, we're unlikely to ever have a std::spawn, so we shouldn't make this change.

In theory, we could make spawn_blocking take a future, since it may want to run a mix of sync and async work.

But whether we do that or not, I'm not sure we want to have spawn as a method on futures.

[joshtriplett]

Closing, since this API wouldn't match future std APIs.