ignition rx running disparity update is sub-optimal

https://github.com/oxidecomputer/quartz/blob/5e7b0fe8a9a0e9a6345f8282f60f7d9c61497b79/hdl/ip/bsv/ignition/IgnitionReceiver.bsv#L344C12-L352C16

I believe this to be a fundamentally incorrect way of determining a receiver's running disparity as it relies on the transmitter transmitting specific patterns on specific disparities, which isn't something you'd typically see in a link. Normally, you'd take the output of your actual 8b10b decoder. It does "work" in our case here because the transmitter is doing extra work to pop between IDLE1 and IDLE2 sequences based on it's running disparity. I believe this was done to facilitate polarity inversion detection but it isn't required and while flipping between IDLE1 and IDLE2 sequences is fine, it really should have no bearing on the rx side's running disparity.

I need to get in and do some actual simulation on this, but all links should generally capture the current running disparity from the 8b10b decoder but i think the resetting of the rd on IDLE sequences can and should just be removed, leaving this state to keep the running disp up-to-date:

https://github.com/oxidecomputer/quartz/blob/5e7b0fe8a9a0e9a6345f8282f60f7d9c61497b79/hdl/ip/bsv/ignition/IgnitionReceiver.bsv#L239

^ The above provides a self-correcting mechanism. Upon link start up you assume some running disparity (say negative) and if you're wrong you get a disparity error (don't care b/c you had a 50-50 chance of getting it right) but you always get your K28.5 comma regardless of polarity inversion. After the first byte, you have a correct running disparity from the decoder, and the next byte can be decoded. Note that you'll never get the wrong decoded byte just due to disparity mismatch, all the byte patterns are uniquely coded.

Longer-term, I think while we can accept IDLE1 or IDLE2 sequences and may continue bouncing between them there's no reason to tie them into a specific running disparity. And regardless of which IDLE sequence you get, the bit-inverse of it is always detectable for polarity inversion, regardless of the running disparity.

Read hdl/ip/bsv/ignition/IgnitionReceiver.bsv around lines 239 and 344-352, then review how the receiver obtains running disparity from the 8b10b decoder and handles IDLE1 and IDLE2. Run or add the simulation the issue calls for to verify disparity tracking and polarity inversion behavior; done means the receiver no longer depends on transmitter-selected IDLE patterns for running disparity.