using sysMonitorWait directly (not monitorWait) is doubly dangerous

If the VM calls monitorWait it is because the thread somehow asked it to, and
we handle the case where sysMonitorWait returns SYS_INTRPT. In other places
where we call sysMonitorWait directly, there are two big problems:
1) We ignore the return value. This means we could go into an infinite loop
   if the wait was in a loop and the thread got interrupted (assuming the
   interrupted state is not auto-clearing.) If the interrupted state is
   auto-clearing (a new semantic change), the fact that the thread was
   interrupted will be lost after the wait.
2) Some code may not be prepared to block. For example the interrupt handling
   thread in Kona has the highest priority and depends on priority inversion
   to keep things moving along while interrupts are disabled. If the VM
   calls sysMonitorWait for this thread, it must block on a lower priority
   thread without the benefit of priority inversion. This means a medium
   priority thread could cause high priority thread to starve because the
   high priority thread is waiting to be notified by a low priority thread.

dean.long@Eng 1996-10-03