Add support for NoMMU

[echelonxray]

On the opposite end of running inside a Docker Container, in a VM, on a Cloud Server, this adds support for running under NoMMU environments.

fork() is not usable under NoMMU because we can't map a separate process into the identical memory address. Instead we will vfork(). We also need a statically linked position independent executable.

The challenge is that technically, until execvp() is called, both the child and the parent share the same memory space, kind of like a thread, but more dangerous because of the shared stack. Technically, we shouldn't be calling other functions like sigprocmask(), setsid(), strerror(), fprintf(), and ioctl() between the vfork() and execvp(). However, the alternative posix_spawnp(), doesn't seem to support making an ioctl, which we need for attaching to a controlling TTY. If we dropped that, it could be used. However, while not strictly guaranteed by the spec, I think this is pretty safe. We aren't overwriting any crazy memory locations or mucking with the stack frame by returning. Under vfork(), the parent is blocked until the execvp() succeeds or the child exits. Therefore, we shouldn't have problems with race conditions. exit() can't be used because it will flush buffers and make calls to registered on-exit handlers with libc within the shared memory space. Therefore, I replaced them with _exit().

Let me know what you think.

[echelonxray]

Force pushed to clean up a stray include statement that I accidentally left when I was playing with posix_spawnp(). I also verified that the commit was signed.

[asottile]

why would one want to use dumb-init for nommu? vfork also seems like a significant risk so unless there's a very good use case for this change I would lean towards rejecting it

[echelonxray]

Oh...I don't know...maybe I do.

Tell me, why is it a significant risk? What is wrong with it?