[cosim] Consider different interrupt/debug request notification mechanism

Nobody has claimed this yet.

Currently the cosim is notified of debug requests and interrupts along with retired instructions via the RVFI interface. Any interrupt or debug request that is signalled with a retired instruction is effectively considered to have occurred in the boundary between that instruction and the previous one.

With a little logic in the RVFI tracking pipeline to ensure it's the first interrupt or debug request that triggers a trap to a handler that gets signalled along with the retired first instruction from a handler this mostly works but suffers because there's no way to indicate temporal differences between different interrupts and debug requests that occur between instructions directly to the cosim instead relying on the RVFI tracking logic to provide the 'correct' interrupt and debug state.

This causes issues where an interrupt occurs and then a debug request or NMI occurs before the first instruction of the handler is fetched and executed. The debug request or NMI takes priority and the first instruction of the original handler is effectively discarded with the mepc/depc of the NMI/debug handler pointing to the first instruction of the original handler..

This is mitigated by this PR: https://github.com/lowRISC/ibex/pull/2014 which introduces a way for the RVFI to signal to the cosim that an interrupt or debug request has occurred between instruction retirements with a special RVFI item that doesn't relate to a valid instruction (but is naturally ordered to the instruction stream due to using the same pipe and interface).

This is somewhat of a quick fix and more elegant solutions should be considered, the current main issues are:

1. The original logic to ensure the 'correct' interrupt or debug request is signalled as part of the retired instruction is still in there. It would be preferable to drop that concept entirely and instead rely on interrupt notifications exclusively with the cosim deciding which is the 'correct' one

2. Do we want interrupt notifications to use RVFI or a separate interface? Mixing with RVFI provides immediate strong ordering but is a bit messy.

3. Separate out interrupt notification from mip/debug req status indication. With the current Ibex behaviour it's possible for one interrupt to trigger a trap handler and then when that trap handler reads MIP (even within the first instruction) for it to see an entirely different interrupt set (this occurs when the original interrupt drops independently without waiting for an acknowledge). To correctly model this the cosim needs to know about the interrupt that triggered the handler separate to the state of MIP for the instructions of the handler and the two concepts are currently intermingled (fixing this may come as a natural consequence of fixing 1 and 2).

Start by reviewing PR #2014 and the RVFI tracking pipeline that currently carries interrupt and debug-request state to the cosim. Compare the ordering, notification, and MIP/debug-status concerns described here. Done means selecting and documenting a coherent notification design, including whether it uses RVFI or a separate interface and how the cosim distinguishes the triggering event from later status.

Written by the indexing model from the issue text.