improve reentrancy behavior/diagnostics during render loop processing

today, reentrancy in the update/render loop can lead to various different behaviors depending on where it occurs. e.g.

1. if an action is emitted to an ancestor node during action processing, the second action may complete before the first, and render the initial reusable sink invalid, thus dropping the action (we may or may not emit any diagnostics in this case... i can't recall offhand)
2. if an action is emitted after action processing & rendering, but before the 'top-level' handling is complete (i.e. the logic to update the root workflow in WorkflowHost), some reentrant cases are attempted to be detected/diagnosed, but some will still cause problems (e.g. see the use case outlined in https://github.com/square/workflow-swift/issues/289)

it would be nice if we had a more holistic story about how we should handle these reentrancy cases. some potential ideas to investigate:

1. make sending actions via Sinks intrinsically asynchronous. this would presumably fix most (all?) crashes due to exclusivity violations for simultaneously mutating state, but might lead to silently ignoring things that may indicate potential issues.
2. improve runtime detection of such reentrancy conditions. this was partially addressed here, but it seems not all potential cases of this manifest in the same way.

Start by reading the reentrancy cases described here, the use case in issue 289, and the prior detection changes in pull request 234. Inspect how Sinks and WorkflowHost participate in action processing and rendering. Done requires an agreed holistic behavior for reentrant actions, consistent runtime diagnostics, and validation of the identified cases.