[13] Useful clone3 wrapper

[Florian Weimer]

* TCB and stack management unclear
* Can we reuse the caller’s stack for vfork-style clone?
* What about TCB?
* Do we need ~50 TCB-less system call wrappers?

We currently have a half-done __clone2 wrapper which has many
limitations: It's not clone3 (d'oh), it's somewhere in the middle
between creating a new thread (as in pthread_create) and re-using the
current thread (as in fork, vfork), and it's unclear what glibc
functionality is allowed to be used from the __clone2 callback function.

A good clone3 wrapper would address these issues.  For example, we could
dictate that the clone3-calling thread will be blocked (vfork-style)
until the callback function returns, so that we can reuse the existing
TCB and stack.  Or we could allocate a new TCB and stack, and add some
life-cycle management for that.  Another alternative would be to add ~50
APIs which mirror core system calls, but they do not use errno for error
reporting and thus do not need a TCB, so only the stack needs to be
managed (which could be easier).

We can also keep extended posix_spawn, or maybe a BPF-style restricted
execution environment for the pre-execve phase.  But I think that's
overdoing it.  Growing the posix_spawn interface is also not ideal
because some things can just not be done with it today.  Running actual
machine code after clone3 on the new thread is conceptually much
simpler, but runs into the TCB issue today.