improve reentrancy behavior/diagnostics during render loop processing

[jamieQ]

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 Workflow host observers are notified before internal updates are finished #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.