Delay releasing of fiber stack in multithread mode

[waj]

This PR fixes an issue found by @asterite in multithread mode (-Dpreview_mt)
For example, this code currently fails with really random and nasty errors:

1000000.times { spawn { } }
sleep 0.1

This is because the fiber stacks are reused but in multithread mode this reuse can happen before the current fiber actually finishes using it.

I didn't add a spec because I don't know how to consistently reproduce it with an example that doesn't involve 1M fibers :)

[ysbaddaden]

Can the queue grow quite big before the scheduler can consider releasing a stack (if the event queue is kept full).

Should removing the fiber from the linked list be delayed, too? A GC collection could start after it's removed, yet before the context switch. Maybe not much impactful thought.

[waj]

The queue only grows when the call to reschedule ends resuming a new fiber, that is, a fiber that has never called reschedule before. Otherwise the resuming fiber will be waiting just within the call to reschedule and it will release the pending stacks before resuming its execution.
We could add a call to clear pending stacks right before a new fiber is started, but in my tests I didn't notice much difference.

Regarding the linked list and the GC, your concern sounds reasonable, but I didn't notice any issue so far. I'll take it into account and address that issue in a different PR if needed.