proc_mux: use assignment action locations for mux src

[widlarizer]

Synthesis users often aim try to reduce the FPGA resource usage or chip area by tracking down what in their designs is causing cells to be emitted by looking at the src attributes Yosys emits. Prior to this PR, the multiplexers created by proc_mux to select the correct values from cases of Verilog switches would be labeled with the source range of the entire switch together with the source range of the entire case (see Note 1). After this PR, the src attribute for such a multiplexer covers exactly the assignments that it implements.

To do this, I'm introducing "RTLIL" state that can't be roundtripped through textual RTLIL, specifically, the Const src field of the new struct SyncAction. Generally the proc passes are considered inseparable from read_verilog, proc converts Processes into cells. I don't believe there is a use case where a user would like to print out RTLIL with processes in it and actually do anything with it. OpenROAD flow scripts does write out canonical pre-synthesis RTLIL but running proc ahead of this seems to be a valid change (see Note 2). If it's attempted, the RTLIL backend has a warning that action sources will be lost. When they are lost, the case src range is used, which I consider still an upgade over the current state of things. I'm also open to alternative approaches.

Before undrafting:

• Fix verific
• Evaluate performance impact and improve if needed
• Write notes about how proc_mux works

Note 1: Also the latter of which was referring only to the end of the case. For example, the $pmux at module tiny2 from the included tests/proc/proc_mux_src.v.
Note 2: See https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/b2918bafbddf77a231fdd5c530cf9d72c1737199/flow/scripts/synth_canonicalize.tcl which refers to https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/b2918bafbddf77a231fdd5c530cf9d72c1737199/flow/scripts/synth_preamble.tcl

[whitequark]

I don't believe there is a use case where a user would like to print out RTLIL with processes in it and actually do anything with it.

Amaranth emits RTLIL with processes in it and would emit fine-grained src attributes if it was available. This functionality should be preserved in textual RTLIL.

[widlarizer]

Oh, I thought Amaranth was emitting flops to avoid proc. I don't want to give preferential treatment to Verilog frontends. This might be best exposed with textual RTLIL v2, which is a good opportunity to get other improvements in. I'll put up a Discourse thread when I gather my thoughts. Exposing this in textual makes sense as a followup but I won't push on this PR until we have some idea what that might even look like

[whitequark]

Oh, I thought Amaranth was emitting flops to avoid proc.

Amaranth still uses processes for decision trees (and there is no reasonable way of avoiding that; we are not going to implement proc_mux in Amaranth backend, that would be a preposterous violation of layering and also really inefficient). It does not use sync rules; it basically only uses proc for the equivalent of always @* blocks. (It makes use of the behavior where a process without sync always rules still generates an always @* equivalent logic.)

We run proc -nomux -norom in the Verilog backend because we want to make use of the Verilog backend behavior of serializing switches as-is.