Notice that a normal send would spawn a local process, send a pid across
distribution, have the local process receive an atom across distribution, and
have the `Msg' be delivered to the requester locally.

That is 1 pid and 1 atom across distribution and one local payload, plus one
spawn that copies the payload.

Doing a call instead will only send back and forth the payload, and already
solve monitoring problems

This is specially optimal when the payload is a literal, like an atom.

Note that in this case, the desired operation will never happen,
and therefore the test has been deemed invalid.

We here revert the changes of the previous commits and instead move the logic
regarding the `async_runner` to a separate module.

This way, the `amoc_throttle_process`'s only responsibility is to track runners
and notify them that they can run; the `amoc_throttle_controller`'s only
responsibility is to assign tasks to processes and control the rates; and
`amoc_throttle_runner`'s only responsibility is to execute the actions.

With this, now `amoc_throttle_process` only tracks the runners and doesn't know
about creating them nor about what operation is it running, and the controller
now only controls the rate, and not the choosing of a worker.

With this, now `amoc_throttle_runner` optimises the different use-cases of the
throttling API: executing arbitrary code, sending a payload, or blocking the
caller.