Provide parent pointers in ContinuationObjects, instead of FiberStacks

[frank-emrich]

This PR:

1. Adds a parent field to ContinuationObject, pointing to the parent ContinuationObject or NULL.
2. Removes the pointers stored near the top of a FiberStack to the parent FiberStack. As a result, the assembly in the fibre crate for dealing with stack switching is now reverted to be identical to the one from the fiber create.
3. The "typed continuation store" field in the VMContext is now consistently used to point to the currently running continuation object, or NULL if not running inside a continuation (i.e., at the toplevel).

These changes also lead to some refactoring of the code for Operator::Resume in code_translator.rs.

[dhil]

Please rebase again, then I will take a look :-) thanks!

[dhil]

LGTM

[dhil]

Yes, I suppose the pseudocode is something like

if parent is null then trap "unhandled tag"
else suspend $tag [args...]

[frank-emrich]

Let's address this once we overhaul error handling in general.

[dhil]

I guess this error should be the same as if forwarding fails, e.g ."unhandled tag". I don't recall the exact message, but it is in the reference interpreter.

[dhil]

I guess we can store the suspend arguments directly on the parent continuationobject instead of mangling with the VMContext now.

[frank-emrich]

We should generally improve error handling, in particular trapping with an appropriate error code.

Regarding storing suspend arguments in continuation objects: You are right, the fact that we now have easy access to the currently running continuation object allows us to store the suspend arguments in there. However, there are a series of efficiency trade-offs: The "global" buffer currently used for suspend arguments can be re-used between different suspends, only being re-allocated whenever it is too small to hold the necessary number of suspend arguments. It also makes the current (rather naive) implementation of effect forwarding more efficient: While buffers local to continuation objects have to be handed over from parent to child (see the cont_obj_forward_tag_return_values_buffer builtin), this is not the case with the global payload buffer in the VMContext.

In total, I would suggest that we continue using the "global" buffer in the VMContext for suspend arguments for the time being, and revisit a better design once we either optimised effect forwarding or implement some kind of pooling logic for continuation objects and/or the buffers therein.

[dhil]

I think it would be good to not mangle with the VMContext too much. I agree that it would be more inefficient in the case of forwarding, but that's only because forwarding is implemented in a particularly naive way right now. Thus I don't worry about that at all.

[dhil]

Just to be clear, I am not suggesting we do this refactor as part of this PR.

[dhil]

I'll merge this one tomorrow

[frank-emrich]

Okay, I've addressed two of your comments, let's leave the remaining two as future improvements.