This PR offers a better solution to the issue described in #546 (in which dependency code doesn't want to receive cancellation events it doesn't know what to do with). Instead of coupling "cancellable" to "async", this PR splits them into two separate immediates, replacing the optional async immediate on yield/wait/poll with cancellable. Since this immediate was not included in the 0.3.0 release, but rather as part of a later 🚟 stackful async release, this shouldn't require any change to 0.3.0 implementations (other than perhaps s/async/cancellable/ in not-yet-implemented validation errors).

A more subtle change in this PR that also doesn't change observable behavior in 0.3.0, but does for the later 🚟 stackful async release, is that synchronous builtins and canon lower no longer have "suspend the component instance" semantics. Instead, the desired "non-reentrancy of sync and async callback core wasm code" invariant is achieved far more directly as part of the semantics of canon lift.

Some advantages of these changes (in the stackful async / cooperative threads timeframe):

• The synchronous and async ABI options are no longer overloaded and decoupled from (1) cancellability, (2) serialization.
• We can over time add cancellable to more built-ins and even canon lower for both sync and async, allowing cancellation to be delivered promptly in more cases.
• Cooperative threads will work just like stackful async exports in that they avoid the non-reentrancy locking entirely, progressing at their own (cooperative) pace, relying on the producer toolchain to handle multiple linear memory stacks etc.