Root current opline result after GC

[arnaud-lb]

Possible fix for GH-13687.

GH-13687 TL;DR:

• Normally, the GC adds live TMPVARs to the roots for the reasons explained in

  php-src/Zend/zend_gc.c

  Lines 2213 to 2216 in 05eda43

  	/* TMPVAR operands are destroyed using zval_ptr_dtor_nogc(), because they usually cannot contain
  	* cycles. However, there are some rare exceptions where this is possible, in which case we rely
  	* on the producing code to root the value. If a GC run occurs between the rooting and consumption
  	* of the value, we would end up leaking it. To avoid this, root all live TMPVAR values here. */

• However this misses variables produced by opN and consumed by opN+1, as these don't appear in live vars

This implements two main changes:

• At the end of a GC run, root the last executed opline's result
• Delay GC runs until a safe point is reached: The GC is now executed in interrupt handlers

The latter point is needed so that we can have some expectations about the VM state (e.g. the last opline's result is initialized), and it's a good thing regardless of this bug, IMHO (e.g. #17246).

There are a few things to consider:

• Interrupts are executed with EX(opline) set to the next opline to execute, not the last one executed. So I root the inputs of EX(opline) instead: If EX(opline) consumes the result of the previously executed opline, it will be one of the inputs.
• Except internal function call interrupts. Those are handled in the middle of the DO_[FI]CALL op while the internal frame is still on the stack, so I root the result of the parent frame, which is the result of the call.
• When walking the stack frame, internal frames indicate that the parent frame is in the middle of the DO_[FI]CALL op as well. Arguments are not consumed yet and must be rooted.

[arnaud-lb]

In JIT:

• Using exits to handle interrupts is useful to make sure that we have a consistent view of the stack in GC. It also keeps the code size small.
• However, the exit may be eventually blacklisted as vm_interrupt will be set more often
• We could introduce a new exit kind that doesn't blacklist
• Alternatively we could exit manually, provided that we handle deoptimization
• WDYT @dstogov?

[dstogov]

I think delaying GC until interrupt handler has its advantages, but this is a significant change that may cause regressions.
I can't dedicate significant time to this task.