[kernel] no guard against a context switch from irq context before EOI

[travisg]

Raised by PR #280 (vishals4gh, continuing the discussion from the accidentally-closed #276), which is being closed in favour of this issue.

The claim: a context switch must not happen from within an interrupt handler before the interrupt has been EOIed to the GIC. If thread_resched() runs before the write to GICC_EOIR, the interrupt stays active at the GIC even after the device deasserts, and subsequent interrupts from that source are never delivered to the CPU.

The PR proposed tracking "this thread is in interrupt context and has not EOIed yet" in the TCB and asserting on it in thread_resched(), implemented for arm and arm64. The author also floated a better shape in the PR comments: put the bookkeeping in kernel/thread.c behind a small API that arch exception handlers call, rather than duplicating it per arch. That second option is probably the right one — the invariant is not arm-specific, even though the failure mode is most obvious with the GIC.

Worth deciding two things before anyone writes code:

1. Whether this is a debug assertion or an enforced invariant. An assertion documents the rule and catches violations in CI; it does not stop a driver from doing it.
2. Whether the existing arch_in_int_handler() is the right hook, or whether it is part of the problem — see arch_in_int_handler not working on multicore ARCH #368, which reports it not working on multicore.