What was changed

Today in places where we wait in a workflow, like wait_condition, we store the Fiber.current on a hash then we Fiber.yield. But when the yield was interrupted by say a timeout or other raised error, we were not properly removing the fiber from the hash. Therefore, later when code happened that would have caused the fiber to properly be resolved, it is obtained from the hash and resumed. But it is no longer yielding there and may be yielding somewhere else. This isn't just wait_condition + timeout, this could happen if you interrupted waiting for activity completion or anything similar to that too.

So where we do this, we updated to make the ensure block after a Fiber.yield remove the fiber reference from the hash so we do not inadvertently resume it later.

This is a fairly rare situation, basically only happens on interrupted fiber yields (basically a fiber raise like Workflow.timeout does). We added a test to prove this situation exists and the fix fixes it for wait condition (did not add tests for every permutation of yield we have).

Checklist

1. Closes ## Bug Report: Fiber state corruption after Workflow.timeout expires on x86_64 #373