Currently, if a caller tries to cancel an async callee while the callee is in the middle of executing a synchronous call to subtask.cancel or {stream,future}.{,cancel-}{read,write}, the synchronous call completes normally and the request-for-cancellation is recorded in the task's state, to be delivered at the next turn of the callback event loop or async waitable-set.{poll,wait} or yield (which are required to expect and handle "cancelled" as a result). The reason for this is that these synchronous calls may happen in the middle of some library/dependency that isn't aware of async or connected to the caller's async runtime and thus doesn't know what to do with being "cancelled", leading to the notification being dropped on the floor instead of propagated to the async runtime. However, synchronous calls to yield or waitable-set.{poll,wait} may return cancellation (if the caller cancels). But it seems like these synchronous calls are in the same boat as the other synchronous calls and thus the "dropped on the floor" hazard is the same.

To fix this, this PR changes synchronous yield and waitable-set.{poll,wait} to have the same non-cancellable behavior as the other synchronous calls mentioned above. The PR also adds a .wast test for this new behavior.