...pending

If two threads are running, with one calling waitpid(-1, Process::WNOHANG),
and another calling waitpid($some_pid), and then
$some_other_pid exits, we would expect the waitpid(-1,
Process::WNOHANG) call to retrieve that exit status. However, it
cannot actually do so until $some_pid _also_ exits.

This patch fixes the issue by calling do_waitpid unconditionally in
waitpid_wait; this will ensure that a waitpid -1 actually reaps
something (after first checking that no PID-directed call wants the
process).

[Bug #20490]

	Don't clear pending interrupts in the parent process. (#10365)

Fix compile error on older systems without clock_get*

	Validate the typed data before dereferencing the internal struct.
	 (#8315)

	---
	 process.c                  |  5 +++--
	 test/fiber/test_process.rb | 21 +++++++++++++++++++++
	 2 files changed, 24 insertions(+), 2 deletions(-)

If two threads are running, with one calling waitpid(-1), and another
calling waitpid($some_pid), and then $some_other_pid exits, we would
expect the waitpid(-1) call to retrieve that exit status; however, it
cannot actually do so until $some_pid _also_ exits.

This patch fixes the issue by unconditionally checking for pending
process group waits on SIGCHLD, and then allowing pending pid-only waits
to "steal" the notification.

[Fixes #19387]

The last part of the sentence was accidentally put in enumeration, It
made an impression that it's one of the rules, not the result of
applying the rules.

Replacing `...` with `*pids` seems to clarify the expected variadic arguments.

Note that the expected arguments are two or more with a signal and pids.
That is, the method must have at least one pid, which cannot be omitted:

```console
% ruby -e 'Process.kill(0)'
-e:1:in `kill': wrong number of arguments (given 1, expected 2+) (ArgumentError)
        from -e:1:in `<main>'
```