[irq] Check whether ISRs need to take into account signal latencies

OpenTitan [standardizes](https://docs.opentitan.org/doc/rm/comportability_specification/#interrupt-handling) on level encoded interrupts, meaning that an interrupt is considered active as long as the level is asserted high. Also, the PLIC treats all interrupt signals as asynchronous, which means that there is a minimum of 3 PLIC clock cycles of delay until a change of the interrupt signal level is recognized at the PLIC side.

Hence, there may exist scenarios where an ISR may be called a second time after it has executed and cleared both the interrupt status bits at the peripheral side and at the PLIC side. This would only happen if the latency of the interrupt signal between the peripheral and the PLIC is larger than the time it takes between the store operation clearing the peripheral bit and the store operation celaring the PLIC bit.

This may not be an issue at the moment, since afaik we do not enable the instruction cache on all test programs yet.
But once we do that and instructions are executed at-speed, this may lead to "false IRQ positives" in some tests.

There are ways to address this on the SW side: e.g. insert a long enough delay between the clearing operations, or make the ISR more permissive so that it can handle false positives when called a second time.

We should keep this issue open until we are confident that either all ISRs are able to handle this correctly, or we can prove that the issue cannot occur in our system based on an execution time analysis (i.e., best case SW execution delay vs worst case HW signal delay).

No source files or tests are named. Start by reviewing the linked interrupt-handling portability specification and inventorying the ISRs involved; the work is done when every ISR handles a possible second invocation correctly or an execution-time analysis proves that the hardware signal latency cannot cause it.

Written by the indexing model from the issue text.