Replace subprocess status ticks with thread events.

Replace subprocess status ticks with thread events.

Without without-interrupts, ticks do not work.  It is possible to
block even though a subprocess has changed state between the last
observation of the global status tick and the suspend.  Passing the
observed tick to suspend-current-thread would allow it to check for
new ticks in the atomic section wherein it decides if the thread
should suspend, but using with-thread-events-blocked for without-
interrupts suggests a "cleaner" solution: subprocess thread events.

The new procedures register-subprocess-event and deregister-
subprocess-event are now used by Edwin in SMPable worlds.  ANY main
loop managing subprocesses AND IO should be using register-subprocess-
event along with with-thread-events-blocked and suspend-current-thread
for SMPability.

Block-on-io-descriptor now uses with-thread-events-blocked instead of
without-interrupts but it does NOT use register-subprocess-event AND
WILL NOT UNBLOCK WHEN A SUBPROCESS CHANGES STATUS.

Unfortunately this breaks Edwin on OS2 and Win32 where it is now
possible for Edwin to block for keyboard input without noticing that a
subprocess has exited.  Edwin's main loop in these worlds needs to be
updated to use a "suspend loop" and register-subprocess-event even
though they do not actually multi-process.

Subprocess-wait now uses a suspend loop like the one in block-on-io-
descriptor rather than blocking for the rest of the thread's timeslice
in the process-wait primitive.  Synchronous subprocess management now
uses this procedure instead of the curious subprocess-wait* (the only
remaining procedure using ticks).

Thus SUBPROCESS-GLOBAL-STATUS-TICK and SUBPROCESS-STATUS-TICK are
eliminated.

Conflicts:
	src/runtime/thread.scm