[alert_handler_escalation] Avoid missing escalation requests

### Description

- In pwrmgr the escalation receiver is clocked by clk_esc_i and outputs esc_rst_req_d, https://github.com/lowRISC/opentitan/blob/master/hw/ip_templates/pwrmgr/rtl/pwrmgr.sv#L139.
- Its output is clocked by clk_lc_i and is used to trigger a reset

There is a similar issue in lc_ctrl, and perhaps in rv_cor_ibex (for NMI requests): escalation requests detected with clk_esc_i and processed with clk_i. However, at least for lc_ctrl we most likely program the threshold to a value enough for any side-effects to complete before the next phase.

The clk_esc_i and clk_i run at the same frequency but clk_esc_i can be gated while clk_i is running. I think this is not a CDC problem for the chip if the alert handler is programmed correctly as explained below.

Once an escalation request is received by pwrmgr it is flopped and will stay active until reset. So the key is whether we can miss a pulse.

The logic driving the escalation requests in alert_handler will move to progressively higher phases whenever a counter reaches a per phase threshold, and will stay in any phase `threshold + 1` cycles. When it moves through all states it reaches a terminal state.

If we want to avoid skipping escalation phases it is safer to program the phase cycles to a positive value for each enabled phase so the escalation request exceeds 2 cycles. For the phase that triggers the escalation hooked up to pwrmgr it could safely be programmed with a really large number, since the resulting reset will erase everything except the crashdump.

Notice even if we add synchronizers we could miss escalation requests if the threshold is zero since a phase could last a single cycle.

This means this is probably a documentation note.