Remove cancellable immediate from built-ins, relax subtask.cancel switching rules

[lukewagner]

Currently, the cancellable immediates of the thread.* and waitable-set.* built-ins aren't emitted by producer toolchains. Also, although not released yet, the currently-specified/implemented behavior of the new thread.{suspend,yield}-then-{resume,promote} built-ins is a bit broken (the single 1 return code conflates 3 different cases guest code probably needs to distinguish: cancelled-before-switch, resumed-because-cancelled, cancelled-after-readied). Rather than fix/test these un-exercised paths, I think it'd be better to just remove cancellable for now and add it back once we need it to enable the "stackful" async ABI (🚟). (I'm also starting to think, when we do need to re-add it, there may be a better design than a cancellable immediate.)

To avoid breaking any existing code (none of which uses cancellable), the PR removes cancellable from the text format, but keeps the cancellable immediate in the binary format and just requires it to always be 0.

Lastly, this PR relaxes the rules for how subtask.cancel resumes the cancelled callee: instead of forcing at-most-1 switch from caller-to-callee-to-caller, the PR replaces this with a plain thread.yield which allows the host to nondeterministically switch to whoever before determining that subtask.cancel blocked. This allows the host to do smarter scheduling (in a way that matches what we allow elsewhere) but also, combined with cancellable-removal, significantly simplifies the rules for cancellation, making them rather easier to understand IMO. See CanonicalABI.md#-canon-subtaskcancel for more details.

The PR updates the tests to not use the cancellable cancellable immediate or expect the relaxed behavior of subtask.cancel, all of which passes on Wasmtime today. The only new test that fails in this PR is the simple binary validation tests in test/binary/binary.wast.