Tracking issue: ease of use

[nrc]

There are many areas of friction around async runtimes, lets try and smooth things out!

Some things that I'm aware of:

• Be able to write async fn main and async tests without a proc macro (this is a pretty complex requirement and ties in with how an async runtime is specified. In particular, I would want to use the specified runtime (rather than a default one) if one has been specified, but what should be used for tests for libraries which should be runtime agnostic? We might want to facilitate running some tests multiple times with different runtimes, or use a special runtime or...)
• Should we include an executor in std? We want new users to be able to get started with async programming as easily as possible, ideally without needing to choose a runtime first. One way to address this is to include a runtime in std. I personally don't think we should (or even can) pick a best runtime, so the std one would have to be minimal with the intention of all serious users swapping it out for a production-ready runtime. But what is minimal? Would supporting block_on but not spawn be ok? Do we need to support IO?

Open issues

[Noah-Kennedy]

I do not think we should expose an executor for std. My main concern is that this will become the standard around which other things will be coupled, making it harder for other runtimes which do IO using different interfaces for example, to integrate with the ecosystem.