[ot] hw/opentitan: ot_uart: model watermark/empty as status interrupts

[moidx]

tx_watermark, rx_watermark and tx_empty are declared as status-type interrupts in the UART HWIP (uart.hjson / prim_intr_hw IntrT="Status"): their INTR_STATE bits track the live FIFO condition every cycle rather than latching, and a RW1C write has no lasting effect while the condition holds. The model treated them as event-type, latching the bit on a receive batch and clearing it only via RW1C. As a result, once software drained the RX FIFO the latched rx_watermark bit stayed asserted, so the next received byte produced no fresh interrupt edge and interrupt-driven RX (e.g. a software-loopback test on ot-earlgrey) would hang.

Compute the status-type bits live from the FIFO levels and OR them with the latched event-type bits when reading INTR_STATE and when driving the IRQ lines, so they assert and de-assert with the hardware condition:

• rx_watermark: rx_fifo_depth >= threshold
• tx_watermark: tx_fifo_depth < threshold
• tx_empty: tx_fifo_depth == 0

Re-evaluate the lines after an RDATA pop and on FIFO_CTRL writes, and drop the now-unused tx_watermark edge-tracking state.

Also align the FIFO depths (TxFifoDepth=32, RxFifoDepth=64) and the watermark threshold mappings (TX saturates at TxFifoDepth/2; RX saturates at RxFifoDepth-2, with rxilvl=7 disabling the interrupt) with uart_core.sv, and only push as many received bytes as the RX FIFO can hold.

[luismarques]

@jwnrt and I looked into this. We created some additional test cases, and in at least one case the behaviour of the OT_UART model is still not correct (double-checked by comparing the FPGA and QEMU executions), and will require follow-up improvements. The next step should be for us to produce a proper PR for those additional test cases. Still, this is a good improvement in correctness, so I think it can be merged, and follow-up commits can address the other scenarios we investigated. See the in-line feedback for some minor points, though.