[GR-34749] Continuation support independent of Project Loom.

[graalvmbot]

This change refactors our fundamental implementation of continuations so it does not require a Project Loom JDK, and adds our own implementation of virtual threads (as opposed to platform threads, i.e. OS threads). With no support in the JDK code for yielding a virtual thread when it blocks on I/O, we cannot ensure progress if we limit the number of backing platform threads, so in the worst case, the default backing thread pool creates a platform thread for each virtual thread. This, of course, currently makes virtual threads less viable for what continuations are usually intended for.

Future changes will refactor the structure of stored continuation stacks and avoid doing stack walks on them eagerly and instead let the garbage collector walk them on demand.

[LifeIsStrange]

I wonder how it compares to Loom and Kotlin coroutines

[peter-hofer]

@LifeIsStrange this implementation is similar to that of Project Loom, but not optimized or well-tested yet. There are some potential advantages we have however, such as our monitor implementation using ReentrantLock which uses LockSupport and so already supports yielding, and not having to worry about interpreter frames. We will not support yielding on I/O blocking though unless the necessary JDK changes are merged, presumably together with the rest of Project Loom.