RFR: Refactor allocation failure and explicit GC handling

[Roman Kennke]

Hi Aleksey,

I like it. This mess was long overdue for some refactoring ;-)

I am unsure about:

> Behavioral change: Explicit GC no longer cancels the concurrent cycle, instead it waits for another
> control loop iteration to start explicit GC. This is for the best, because it both simplifies our
> handling logic, and allows requesters to wait for their own cycle. This is interesting when
> concurrent cycle is running, ExplicitGCInvokesConcurrent is enabled and System.gc() is called: the
> requesting thread would wait for one complete GC cycle to start and finish.

That does mean that System.gc() at the beginning of marking would wait 
until marking+evac(+updaterefs?) finishes, then does the full-gc, and 
only then is the Java thread allowed to progress? I guess it does not 
really matter very much, but what is the point to wait for current cycle 
completion if it goes into full-gc anyway? I guess it is more relevant 
with ExplicitGCInvokesConcurrent (as you point out).

Other than that, it is good for me.

Thanks, Roman