RAM rewriting causes artificial responses on RAM write channel

**Describe the bug**

For [RamDemux](https://github.com/google/xls/blob/9c1e05d43bd453bbb8afbe71a35a13b1ebc50bc8/xls/modules/zstd/ram_demux.x#L37) proc that we created to allow access to two RAMs from one pro, applying RAM rewriting causes incorrect behavior of the system in Verilog. Specifically, after RAM rewriting is applied, the proc begins to emit artificial responses on the write response channel even though no write requests were ever sent. The problem only shows up after applying the RAM rewrite pass, as the simulation without this step behaves as expected.

We suspect the problem is related to RAM rewriting being applied to non-blocking receive statements. This case might not be handled correctly by the pass. We believe this because when we wrapped the outputs of the RamDemux with additional [RamPassthrough](https://github.com/antmicro/xls/blob/a5e063f39581be8633a2d92447353b52035355f5/xls/modules/zstd/ram_passthrough.x#L159) procs (which use blocking I/O), and then applied RAM rewriting, everything started working correctly.

I created a simple simulation showing the problem, that is available at:
https://github.com/antmicro/xls/tree/ram_rewrite_issue

**To Reproduce**
Steps to reproduce the behavior:
1. Check out the `ram_rewriting_issue` branch from our [XLS fork](https://github.com/antmicro/xls/tree/ram_rewrite_issue)
2. Execute the following command:
```bash
bazel run -c opt //xls/modules/zstd:ram_demux_cocotb_test
```
3. The script will run three test cases. Their results will be printed in the terminal log. One of them should fail.

4. Each test generates an FST waveform file that can be analyzed using a waveform viewer like GTKWave. Look for lines in the logs that start with:
```
FST info: dumpfile /path/to/output.fst
```

These lines show where each waveform file is saved.

**Description of the test cases**

The test writes data first to the first RAM, then switches to write to the second RAM. After that, it switches again to read from the first RAM and then from the second RAM, checking that the values are correct.

- The first test shows the proc’s correct behavior without RAM rewriting. In this case, no extra traffic appears on the write response channel.

- The second test shows the `RamDemux` proc **after** RAM rewriting. Here, artificial responses are generated even before any write requests are sent.

- The third test wraps the `RamDemux` proc with an additional passthrough proc using blocking I/O. In this case, no responses are sent before the corresponding requests.

**Expected behavior**
No additional traffic should be visible on the write respose channel, before issuing any responses.