Use boolean allocation options

[wks]

We remove OnAllocationFail and add three boolean fields to AllocationOptions:

• eager_polling: whether to poll before acquiring pages from the page resource
• allow_overcommit: whether we allow overcommit
• at_safepoint: whether this allocation is at a safepoint

This will allow new combinations that cannot be expressed by the previous OnAllocationFail type. Particularly, it allows both polling and over-committing to happen in one allocation attempt. If this allocation is also not at a safepoint, this combination will allow the current mutator to allocate normally in this allocation, but block for GC at the nearest safepoint.

Note: This PR implements the idea proposed in #1382 (comment). I created a new PR because the resulting commit will be radically different from #1382.

TODO:

• Rebase this PR upon Refactor Space::acquire #1401 after Refactor Space::acquire #1401 is merged.
• Check if AllocationOptions can still be stored and loaded atomically. It should suffice if its size is smaller than the word size. If Rust is unhappy with three boolean fields, replace it with a bit field. AllocationOptions cannot be loaded or stored atomically. We replaced Atomic with RefCell.

This PR supersedes the following PRs:

• Allow requesting GC while over-committing. #1380
• Change the semantics of OverCommit to allow polling #1382

[wks]

After this PR, the decision tree becomes: (assuming this is a mutator thread, and GC is already initialized)

• Does the allocation option allow eager polling
  • If yes, poll, and move on.
  • If no, just move on.
• Is any of the following true? (a) The poll above didn't trigger GC (Consider it "not triggered" if we skipped polling), or (2) the allocation option allows over-commit
  • If yes, try to get pages from the page resource, and move on.
  • If no, just move on.
• Have we got pages from the page resource?
  • If yes, do the mmapping and return the address.
  • If no, are we at safepoint?
    • If yes, then
      • Have we tried getting new pages from the page resource?
        • If yes, force a GC, and move on.
        • If no, just move on.
      • block for GC.
      • return NULL.
    • If no, then return NULL immediately.

The control flow is more linear than before, with three steps, each using one boolean option.

By combining the three options, we can replicate the behaviors of the previous OnAllocationFail variants.

Variant	eager_polling	allow_overcommit	at_safepoint
RequestGC	true	false	true
ReturnFailure	true	false	false
OverCommit	false	true	false

We can make a new combination to poll (scheduling GC in the background) and overcommit at the same time, and postpone blocking for GC to the next safepoint. This can be useful for VMs where allocation never happens at safepoints.

new behavior	eager_polling	allow_overcommit	at_safepoint
both poll and overcommit	true	true	false

But I wonder whether we can remove the eager_polling option (i.e. always making it true). I can't think of any use cases where we don't want to poll. Polling only affects GC threads in the background. Even if GC is not initialized at this time, GC workers will be able to start the first GC immediately after GC is initialized. So it seems to be harmless to let it poll all the time.