Add first batch of async support

[lukewagner]

This PR adds a first batch of async support, viz., the async and callback options to canon lift/lower and the supporting canonical built-ins. The PR does not add future or stream, those will be in the next PR (as well as a number of other key parts of the async story; see Async.md#TODO).

There are two commits in the PR, a tiny one that removes something and a big one that adds all the async stuff.

The first commit removes a special case where reentrance was allowed in a very hand-wavy manner for parent-->child-->parent cases. Working through async and thinking about what reentrance even means in an async context, I realized that the hand-wavy approach was wrong and the better way to enable this use case is by adding a new reentrant (name TBD) attribute to function types that basically opts into reentrance at the type-level, allowing parent-->child-->parent reentrance as a special case. I'm pretty sure this won't break any code because it requires doing "donut wrapping" which isn't supported by the producer toolchains yet. Adding reentrant is in the Async.md#TODO list.

The second commit is somewhat big and I'd recommend reading it by:

• Start by looking at the additions to Explainer.md and Binary.md, which are pretty small.
• Read the new Async.md to get the high-level summary and terminology.
• Read the delta to CanonicalABI.md to understand how it all works in detail.

Big thanks to @dicej who has been collaborating on this design and has built a working prototype that we'll now iterate on to precisely match this PR. (Apologies in advance for slow replies over the next week due to in-person wasm CG meeting.)

[sunfishcode]

It might provide useful context to mention how this proposal relates to the stack-switching proposal; that is, that it doesn't depend on stack-switching, but stack-switching could be used in conjunction with it.

[dicej]

Are we sure we want to commit to cancellation for Preview 3? I'm concerned it adds a lot of scope, delaying the release. As usual, I'm always looking for opportunities to reduce scope so we can deliver the valuable pieces we've already got a firm handle on ASAP.

[lukewagner]

I think cancellation ends up being an integral part of the async "protocol" (which, if you ignore, ends up being a breaking change to add later) which makes me think we need it in the initial shippable unit. Also, my impression is that, while it takes some careful state-transition thought, it won't actually be that bad or that much impl work (in the runtime, at least -- language bindings will have more fun).

[lukewagner]

Thanks for all the feedback! I'll merge for now, but of course what's proposed here is expected to change as the implementation progresses and also the remaining async functionality (listed in Async.md#TODO) is filled out. I'll start working on the next PR with the next batch of functionality (I'm thinking stream) once I finish the PR for BuildTargets.md.