Add cocotb tests for AXI peripherals

[lpawelcz]

This PR extends #1613 by adding Verilog simulation and tests for MemReader, AxiWriter and MemWriter procs. The simulation and testing is carried out with cocotb framework and Icarus Verilog simulator. The PR also includes utilities for driving and monitoring DSLX channels by the cocotb framework.

Cocotb and the provided utilities are Python packages and don't require any special rules in the workspace. The utilities we created are generic, and although they were placed in the xls/modules/zstd/cocotb directory, they can be moved to another location if this is more desired.

Please note that this code is based on top of #1613 so the diff also contains all the changes from that PR. The IR generation for the MemWriter proc is also blocked by #1615.

[lpawelcz]

CC @proppy - please take a look at this PR

[proppy]

Does this replace #1057?

[rw1nkler]

Regarding the content, this PR uses the ideas from #1057 but provides more helpers for writing the simulations.
The previous PR was adding cocotb to a different directory, for use in other places in the workspace. Here we provide the scripts directly in the modules/zstd directory. We can discard the previous PR, if you think that it is easier to merge the cocotb support with the AXI tests, or we can move the created libraries to #1057 and merge them separately.

[proppy]

We can discard the previous PR, if you think that it is easier to merge the cocotb support with the AXI tests

I think it'll be easier to maintain it along side the zstd modules for now, and we can generalize it to the wider xls project as it matures.

[lpawelcz]

@proppy we rebased the PR onto current state of the #1613 and updated cocotb testbenches to take into account the changes made to MemReader and MemWriter

[proppy]

rebase?

[lpawelcz]

Rebased onto newest main

CC @proppy

[lpawelcz]

CC @proppy

The last CI failure was caused by benchmark_main segmentation fault in DecoderMux proc IR benchmark.
This is an unrelated issue as we also experienced the same failure on current main. It appears that this particular IR benchmark started failing randomly.
We are investigating the root cause of the problem. We noticed that the failure happens when the Block IR is evaluated with JIT. The evaluation is carried out with a random set of inputs which explains the unpredictable nature of the failures.
The problem might be caused by the usage of assert!() inside the proc but for now we were unable to prepare a minimal example for that.

[lpawelcz]

@proppy closing this PR as it was superseded by #1857