Api::resume() and throw() make it difficult to integrate with sync code.

[jmalloc]

The intent of these methods was to provide a way to resume strands as part of the kernel API, so that it may be versioned independently of the underlying strand implementation (#124). However, using these operations (exclusively) means that you can't resume strands from outside a coroutine.

Long story short, there needs to be a way to resume strands from "regular PHP code" that is part of the public API. Strand already implements Listener, so perhaps this is as simple as packaging and versioning Listener along with Api.

FYI @koden-km

[jmalloc]

Specification wise this would also mean the first callback to Recoil::suspend() should accept Listener rather than Strand specifically.

We could take this further and make Api::send() and throw() take listeners too, though I'm not sure if this is actually a good idea - if Listener is to be considered part of the kernel API then there's probably no need for the Api methods at all - perhaps then they could go back to their original behaviour of resuming on the next-tick, rather than immediately.

[jmalloc]

So after discussion today, the question is, do we:

(a) remove Api::resume() and throw() altogether
(b) revert them to their original 'next tick' behaviour

[jmalloc]

Let's remove them. They offer no immediate value if Listener is considered part of the kernel API.