hubris should have more knowledge of sequencing failures when trying to go to A0

[nathanaelhuffman]

Rather than just report all of the rail status bits and hardware state machine states, it should also provide information about which rails we were expecting given the current state to make diagnosis easier. This is straight forward and all of the information required is available in fpga registers if hubris knew which ones were expected in each state

[nathanaelhuffman]

You can find the cosmo sequence here for reference: https://github.com/oxidecomputer/quartz/blob/b9428476b5903b87953d8e82755706a53ae88b92/hdl/projects/cosmo_seq/sequencer/a1_a0_seq.vhd#L243

we pause at GROUP_A_PG_AND_WAIT for the following rails:
v1p5_rtc.pg, 3p3_sp5_a1.pg and v1p8_sp5_a1.pg

we pause at SLP_CHECKPOINT for two bits of handshake from the AMD CPU and the DDR bulk HSCs power good:
abcdef_hsc.pg power_group.ghijkl_hsc.pg and

slp_s3_l = '1' from AMD CPU
slp_s5_l = '1' from AMD CPU

we pause at GROUP_B_PG_AND_WAIT for the following rails:
v1p1_sp5.pg

we pause at GROUP_C_PG_AND_WAIT for the following rails:

power_group.vddio_sp5_a0.pg and 
power_group.vddcr_cpu1.pg and
power_group.vddcr_cpu0.pg and
power_group.vddcr_soc.pg

we pause at WAIT_PWROK for the PWROK from AMD CPU

we pause at WAIT_RESET_L_RELEASE for the RESET_L release from the AMD CPU.

We should have live visibility to all of these rails and bits in FPGA registers, so when we timeout in one of these states we should report those that were not as expected to make diagnosis

[mkeeter]

See also https://github.com/oxidecomputer/quartz/blob/ndh/a0-fault-tree/hdl/projects/cosmo_seq/sequencer/docs/a0_sequencing_fault_tree.md