Fix a bug in Fiber.finalize

[ghost]

This fixes #2958.

The problem was the finally was called too late in case of error. I also removed wait_errors from the API as it's unused and it seems like it could cause the same issue.

[aalekseyev]

Hmm, I find both versions of this function suspicious.

Before this PR, finally would run only after all errors are handled, which, as you say, is a bit too late.

After this PR, finally runs just before the first error is handled. If the concurrent fibers continue executing after that error, we have finally running during execution, which I think contradicts the docs.

Maybe a good behavior is to have finalize collect all errors without handling them until all computations are done and then run finally and emit all errors to the surrounding handler?

[ghost]

Indeed, I hadn't considered we would still have code from f running after after finally has been called. Buffering errors seems like the right thing to do indeed. Doing that.

[ghost]

I reworked the code. The result is probably not as efficient as it could be, but at least the implementation of finalize is straightforward.

I also changed collect_errors so that the errors are reraised in the same order as they were originally raised.

[aalekseyev]

Looks good