[dv/cip] Handle random CDC delays inside `prim_alert_sender` in DV

Nobody has claimed this yet.

If random CDC delays are enabled in `prim_alert_sender`s, the scoreboard (usually `cip_base_scoreboard`) does not know precisely in which clock cycle the handshake for an alert completes and thus cannot accurately predict whether an alert request gets merged with an outstanding request or not.

For context, here's an example:
- At the first blue marker, the alert sender gets a request (`alert_req_i`). One cycle later, it sets `alert_p` high.
- At the second blue marker, the alert sender gets another request. In the meantime, it has received `ack_p` high, but as this is a four-phase handshake, the HS is only complete once `ack_p` will be low again. (Also see `state_q`.)
- At the third blue marker, the alert sender gets the third request. In the same cycle, `ack_p` has gone through the 2FF (including an extra cycle CDC delay), so alert sender acknowledges all three requests with one `alert_ack_o` high.

Note that this issue is mostly orthogonal to the problem that `ack_p`/`ack_n` form a differential pair and only one of the two signals could get an extra cycle delay. In this case, the scoreboard would also have to know that the handshake completes a cycle later.

Related: [Enable CDC instrumentation for alert_handler (#18070)](https://github.com/lowRISC/opentitan/issues/18070)

Start by reading prim_alert_sender and the cip_base_scoreboard behavior described in the issue, then review the related alert_handler issue #18070. Reproduce the random CDC-delay scenario in DV and trace when the four-phase handshake completes. Done means the scoreboard accurately predicts merged alert requests despite randomized delays.

Written by the indexing model from the issue text.