Make vm_interrupt and timed_out atomic

[morrisonlevi]

On Windows these are already set from another thread and should be
atomic. On Linux it is unclear to me if this should be done based on
the existing code.

However, extensions which use vm interrupts are very likely to do the
same thing that Windows is doing: set a vm_interrupt from another
thread.

This combination suggests to me that this change is overdue.

This change is pretty trivial: I expect any issues to arise from from build
system changes or adding compiler flags, etc.

[morrisonlevi]

The largest issue here is that the vm_interrupt global is in a header and the layout needs to be ABI and source compatible between C and C++. At this time, this cannot be done cleanly across platforms. Both C and C++ have atomic_int, atomic_bool, etc, but critically in C++ all implementors (major ones, at least) have defined these as std::atomic<int>, std::atomic<bool>, etc which means they cannot be used in an extern "C" {} section. This is the first major hurdle.

The second is that there is no ABI guarantee in the standard that int and _Atomic(int) and std::atomic<int> have the same size, alignment, and layout. There are discussions about this for C++23 and C23 and there are some issues out there, though I'm not sure we'd actually hit any of them with a simple atomic_bool.

Here are two options I can think of to fix this:

1. Check size, alignment, and layout during configuration, and enable atomics if and only if they match and define them as maybe_atomic_bool or something. Platforms which don't match would behave as today (not atomic). Additionally, every header file would have to be made directly C++ compatible, and all extensions would have to stop including PHP headers in extern "C" {} sections.
2. Move it out of the globals and provide a non-inline API for it which is then implemented using C atomics. This is probably at least a slight annoyance for extensions which trigger interrupts, but the end-result for such extensions is better: the atomicity will actually be enforced.

Honestly, the latter sounds like a better option to me. Thoughts?

Rough API, inspired by the C atomics APIs but without user-provided memory orderings (would use seq_cst):

bool zend_vm_interrupt_compare_exchange(zend_executor_globals *, bool *expected, bool desired);
bool zend_vm_interrupt_exchange(zend_executor_globals *, bool desired);
bool zend_vm_interrupt_load(const zend_executor_globals *);
bool zend_vm_interrupt_store(zend_executor_globals *, bool desired);

I'm not sure about using zend_executor_globals * as the pointer, but often these are referred to by other threads so we can't just assume "use the current thread". Need to provide some handle, not sure what that should look like.

[morrisonlevi]

Nikita suggested I look into using only atomic operations, not an atomic type, to see how that goes. I'll try that the next time I get a moment to work on it.

[morrisonlevi]

Closing in favor of a fresh PR.

[Krinkle]

For future reference, the fresh PR is at #8327