Indefinite parsing and type-checking loops for some parameterized procs

[lpawelcz]

Describe the bug
While working on #1613, we encountered an issue linked to afc720d, which appears to cause indefinite parsing and type-checking loops for certain files, such as mem_writer.x (provided in this PR).

To Reproduce
Steps to reproduce the behavior:

1. Checkout on the branch from Add procs for interfacing with AXI peripherals in ZSTD Decoder #1613
2. Execute the command bazel build -c opt //xls/modules/zstd/memory:mem_writer_verilog
3. Observe indefinite loop in parsing and type-checking mem_writer DSLX files:

    Converting DSLX file to XLS IR: xls/modules/zstd/memory/mem_writer.x; 48s remote-cache, processwrapper-sandbox
    Parsing and type checking DSLX source files of target mem_writer_dslx; 48s remote-cache, processwrapper-sandbox

4. Cancel bazel build
5. Revert afc720d
6. Repeat the bazel build command: bazel build -c opt //xls/modules/zstd/memory:mem_writer_verilog
7. Observe correct IR and verilog generation for the MemWriter proc.

Expected behavior
Toolchain should be able to generate IR for the provided MemWriter proc .

Additional context
This is a blocker for #1613 and as a consequence also for #1211.

[richmckeever]

What's happening here is that a couple of bugs, which are inconsistent sequencing of the parametric pattern "AxiStream<DATA_W, DEST_W, ID_W, DATA_W_DIV8>" in the zstd code, are exposing parametric env leakage in type checking, where we build maps like:

DEST_W => DATA_W_DIV8
DATA_W => DATA_W
DATA_W_DIV8 => ID_W
ID_W => DEST_W

and then try to figure out what e.g. DATA_W_DIV8 is, using such a map.

The faulty "AxiStream" are in axi_writer.x and mem_writer.x. You may be able to get unblocked by fixing those to be consistent with the struct declaration. In the meantime I will work on a fix in the type checker.

[lpawelcz]

@richmckeever thank you so much for pointing the errors in the sequencing of the parameters! I was able to fix those and generate the IR without problems.