Simpler clone

[fwsGonzo]

This replaces the syscall-based cooperative threads with call-based, which will be much much faster. Also removes the children-management, which never had any use. Threads are much slimmer now.

Also improves reliability of blocking calls. It was possible for the system to go to sleep while the event that would have unblocked had already been processed. Fixed now.

This PR needs musl 1.1.24 to work.

[alfreb]

We'll get to this once everything is building again 😊

[alfreb]

Hi, I've finally gotten around to this. As we've discussed offline, we will branch off 0.16.x from v0.15.0 to recover the original SMP implementation without pthreads (which we have thanks to you), but I'd be also be happy to have the "all pthreads" approach as a separate platform. We could split x86_pc into

1. x86_smp, the v0.15 SMP model and
2. x86_pthread, the full-on SMP with pthreads kernel currently on master. As it seems that we both want the x86_smp without pthreads to be the default, I've now created a branch https://github.com/includeos/IncludeOS/tree/pthread-kernel where you can continue this work if you'd like, until we figure out if and how to integrate everything. That branch boots with ./minimal-test.sh - but there's at last one ghost 👻

I've also tried to merge this PR and upgraded to musl 1.1.24 in a new branch, https://github.com/includeos/IncludeOS/tree/pthread-kernel-musl-1.1.24

That branch however, fails to initialize libc and keeps rebooting for me. I don't think this PR causes that issue - on the contrary I think there's been a latent ghost on master, probably since before v0.15, which may be related to the new toolchain and new compiler, to my mmap / allocator changes that we shoehorned in, or something else entirely. I'll be reworking the boot sequence in the new release branch to try to simplify all of that and will then revisit both of the mentioned pthread branches once we get to a state where we have something running with the original SMP library again, and importantly, tests and ideally CI.

If you decide to get this into a working state, feel free to take ownership over pthread-kernel at any time, and cherry pick what you find useful from pthread-kernel-musl-1.1.24 (I have newer musl working there). You can then reintegrate this PR on top of pthread-kernel and delete pthread-kernel-musl-1.1.24. We can then leave it as a prototype until we get v0.16.0 into a decent shape and consider creating a separate platform for the pthread kernel.