After the library successfully called fork(2), the child does several
setup works such as setting UID, GID and current directory before it
calls exec(2).  When those setup works failed, the child exits but the
parent didn't call waitpid(2) and left it as a zombie.

This patch also add several sanity checks.  They shouldn't make any
noticeable impact to runtime performance.

The new test case run-pass/wait-forked-but-failed-child.rs calls the ps
command to check if the new code can really reap a zombie.  When
I intentionally create many zombies with my test program
./spawn-failure, The output of "ps -A -o pid,sid,command" should look
like this:

  PID   SID COMMAND
    1     1 /sbin/init
    2     0 [kthreadd]
    3     0 [ksoftirqd/0]
...
12562  9237 ./spawn-failure
12563  9237 [spawn-failure] <defunct>
12564  9237 [spawn-failure] <defunct>
...
12592  9237 [spawn-failure] <defunct>
12593  9237 ps -A -o pid,sid,command
12884 12884 /bin/zsh
12922 12922 /bin/zsh
...

Filtering the output with the "SID" (session ID) column is a quick way
to tell if a process (zombie) was spawned by my own test program.  Then
the number of "defunct" lines is the number of zombie children.
Signed-off-by: NNODA, Kai <nodakai@gmail.com>