[coop] Hybrid suspend

## Summary

This is a new suspend mode where threads that are running managed or native runtime code (what we call "GC Unsafe") are suspended cooperatively using safepoints, but threads running either embedder code or P/Invoke code or blocking syscalls (what we call "GC Safe") are suspended preemptively using signals.

The motivation is to make an embedder-friendly coop suspend mechanism where the runtime will do GC Safe -> GC Unsafe transitions on calls to `MONO_API` functions, but the embedders themselves don't have to have any special knowledge of coop safepoints or state transitions.

To try this out, set **both** `MONO_ENABLE_COOP` and `MONO_ENABLE_HYBRID_COOP` environment variables.

## Implementation

Here's a picture of the new state machine.  There's two new states `Blocking_Suspend_Requested` and `Blocking_Async_Suspended` and one updated transition `req_s` (request suspension).

![coop-state-machine](https://user-images.githubusercontent.com/480437/38572948-9fe879e2-3cc2-11e8-8f27-9493f05f03bf.png)

### State machine states and transitions

The hybrid cooperative suspend mechanism works like this:
 - when a thread is executing in GC Unsafe mode, we use cooperative suspend and expect
   the thread to periodically checkpoint its execution (as in the ordinary full
   coop mode).
 - when a thread is executing in GC Safe mode, we use a preemptive signal-based
   suspend.  This is new - previously in full coop we would allow `BLOCKING`
   threads to continue executing and only suspend them when they wanted to go
   from GC Safe to GC Unsafe (via the `BLOCKING_SELF_SUSPENDED` state).

There are two new states and one updated transition - the transition will
service both running and blocking threads: The idea is that suspend mechanism
is determined by the suspend initiator, and is not embodied in the the state
machine.  The state machine just has to return distinctive enough values from
the transitions for the initiator to select a policy.

Resume mechanism is determined by the state that a thread finds itself in when
it is resumed, and the original suspend policy.

The primary differences between suspend mechanisms are: the preemptive
suspend is two phase - the `finish_async_suspension` does not
apply for cooperative suspend; the cooperative policy uses the `poll` transition when the thread is running.

We renamed `mono_threads_transition_request_async_suspension` to `mono_threads_transition_request_suspension`.

 - It must be called by a suspend initiator on a victim thread that is not
   itself.

 - There can only be one suspend initiator for a victim at a time - if the
   suspend initiator initiates a suspension it must follow through with the
   whole protocol.

 - If a victim is `RUNNING` we transition it to `ASYNC_SUSPEND_REQUSTED` and return
   `ReqSuspendInitSuspendRunning` which signals that the caller must initiate
   suspension for a running thread.  (Same as the old `AsyncSuspendInitSuspend`).

 - If a victim is `BLOCKING` we transition it to `BLOCKING_SUSPEND_REQUESTED`.
   Note that this is different from the old `request_async_suspension` which just
   incremented the suspend count and returned `AsyncSuspendBlocking`.  Now we
   return `ReqSuspendInitSuspendBlocking`.  The return of
   `ReqSuspendInitSuspendBlocking` means the initiator may signal the victim and
   must wait to be notified of the suspension (in preemptive suspend it will be
   notified by the signal handler, in cooperative when the blocking thread
   attempts to exit from blocking mode).

 - In `BLOCKING_SUSPEND_REQUESTED` we
   may increment the suspend count.  This is slightly too lax if we're going to
   be using preemptive suspend on blocking threads: in that case we're in the
   middle of a two-phase suspend and since there is only one suspend initiator,
   we wouldn't expect another suspend to be initiated until we have a chance to
   finish suspending.  We leave it to the suspend initiator to rule out by returning
  `ReqSuspendAlreadySuspendedBlocking` from this state.

 - In all the not executing states (`SELF_SUSPENDED`, `ASYNC_SUSPENDED`,
  `BLOCKING_SELF_SUSPENDED`, `BLOCKING_ASYNC_SUSPENDED`) we just
   increment the suspend count.

 - All other transitions are illegal.

- Note that `BLOCKING` must always have a suspend count of 0 and
   `BLOCKING_SUSPEND_REQUESTED` must have suspend_count > 0.

We add two new states:

 - `STATE_BLOCKING_SUSPEND_REQUESTED` - this is a new state that indicates that a
   suspend initiator wants to suspend this victim thread.
   - The thread is still executing in this state.
   - We only transition into this state with
     `mono_threads_transition_request_suspension`.
   - The only legal transitions out from this state are:
     - `resume` - decrements the `suspend_count`. If the `suspend_count` becomes 0 we
       go back to `BLOCKING`, otherwise we stay in `BLOCKING_SUSPEND_REQUESTED`.
     - `finish_async_suspension` (executed by the suspend signal handler to
       finish the two phase preemptive suspend request and notify the suspend initiator),
     - `done_blocking` and `abort_blocking`.  It means that the a
       suspend initiator requested a suspend but we got to done (or abort)
       blocking before the signal was delivered. We return `NotifyAndWait` and the
       caller is supposed to send a notification to the suspend initiator and
       wait for a resume(with suspend count == 0) which will return to
       `RUNNING` (the victim thread goes to `STATE_BLOCKING_SELF_SUSPENDED`).
 - `STATE_BLOCKING_ASYNC_SUSPENDED`
   - The thread is not executing in this state (it is waiting for a `resume`).
   - a thread transitions into this state from `STATE_BLOCKING_SUSPEND_REQUESTED`
     on a `finish_async_suspension` transition (see above).
   - on a `resume` transition we decrement the suspend count. if it's still
     positive we stay in this state. if it's 0 the thread transitions out of
     this state.  Unlike other resume transitions, in this case the thread goes
     back to `BLOCKING` and resumes executing in GC Safe mode.  The resume caller
     must notify the resume initiator (ie this is a `ResumeInitAsyncResume`).
   - on a `request_suspension` we stay in this state and just increment the
     suspend count.
   - all other transitions from this state are illegal.

We add two new return values for `abort_blocking` and `done_blocking`:
  - `DoneBlockingNotifyAndWait` and `AbortBlockingNotifyAndWait`. Similar to
    `SelfSuspendNotifyAndWait` - there was a race between the second phase of a
    preemptive suspend and another operation (in that case a poll, in this case a
    done or abort blocking) and the other operation won, so its caller should
    notify the suspend initiator. Since the thread is now suspended, the caller
    should wait for the resume signal.

We add new results for `request_initiate_suspension` `MonoRequestSuspendResult`
(formerly `MonoRequestAsyncSuspendResult`):
  - `ReqSuspendAlreadySuspended` means the thread is not executing and we just
    incremented its suspend count and there's nothing else for the suspend
    initiator to do. (The old `AsyncSuspendAlreadySuspended`)
  - `ReqSuspendAlreadySuspendedBlocking` means the thread is in
    `BLOCKING_SUSPEND_REQUESTED` and we initiated another suspend request.  This
    should only happen with full cooperative suspend - with hybrid suspend we
    will use a two phase preemptive suspend on a blocking thread and since only
    a single suspend initiator is active, this state should not be visible to
    another suspend initiator.
  - `ReqSuspendInitSuspendRunning` - Thread is executing in GC Unsafe mode and the
    caller should suspend it.  This is the old `AsyncSuspendInitSuspend`.  In
    full preemptive suspend this is the only suspend initiation action and the caller
    should begin the preemptive suspend procedure.  In full coop we expect the
    victim thread to reach a safepoint and poll to finish suspending.
  - `ReqSuspendInitSuspendBlocking` - Thread is executing in GC Safe mode and
    the caller should initiate a suspend.  In full coop the caller has nothing
    to do - a thread executing in blocking mode is assumed to be suspended.  In
    hybrid suspend, the caller has to initiate a preemptive suspend.

### Suspend initiator, signal handler, self suspender

Basically we call `mono_threads_transition_request_suspension` instead of `mono_threads_transition_request_async_suspension`.
Then if it says to suspend a running thread we call `begin_suspend_for_running_thread`, if it says initiate a suspension of a blocking thread, we call `begin_suspend_for_blocking_thread`, and if it says do nothing we do nothing.

**Questions**
1. We have an assumption in `safe_interrupt_thread` that we can return from a self interrupt if we're using coop suspend.  I'm not sure if that makes sense for hybrid suspend, and not clear what to do about it.
2. In `mono_thread_info_safe_suspend_and_run` we expect that the callback won't return `KeepSuspended` if coop is enabled.  I'm not sure what this means for hybrid.
3. A bunch of tests like `monitor-abort` and `appdomain-threadpool-unload` are failing if I enable hybrid suspend.  Don't know why yet.


Commit migrated from mono/mono@529e486