[enhancement] Replace interpreted RamModel with C++ model in DSLX interpreter

### What's hard to do? (limit 100 words)

Running simulations with the DSLX interpreter is slow when using the `RamModel` written in DSLX, and results in increased RAM consumption, as pointed out in https://github.com/google/xls/issues/1042 and https://github.com/google/xls/issues/1897 . This is because relatively simple constructs are wrapped in interpreter values, which introduce a lot of overhead. JITed version of the RamModel should also be slower than a native ++ implementation.

On my platform, the JITed tests of `RamModel` tests take even longer than the one using the DSLX interpreter, which is suspicious ([code](https://github.com/antmicro/xls/tree/80209-jited-ram-model-tests)).

### Current best alternative workaround (limit 100 words)

Right now, the DSLX `RamModel` is used even though it’s slow. Some tests avoid RAM or use smaller memories to make it bearable.

### Your view of the "best case XLS enhancement" (limit 100 words)

Replace the DSLX `RamModel` with a C++ model inside the DSLX interpreter. This would keep the simulation flow the same but make RAM access much faster. It would speed up RAM-heavy tests without changing user code and improve the development loop. In the simplest case, fixing the JIT for `RamModel` should be sufficient, as this should already give a speedup compared to the interpreter. However, a separate C++ `RamModel` may also be beneficial and could introduce features like reading/writing to a file or hooking into specific address writes. In terms of memory usage, this approach would enable efficient simulation of real-life buffer sizes. The C++ model could also generate traces showing changes in RAM contents, which would help spot undesired accesses.

Also, the current `RamModel` is not just an example, but rather an integral part of the toolchain that has its own RAM rewriting mechanism. Because it’s so connected to the rest of the toolchain, it may be beneficial to make it a built-in. Having it in the DSLX interpreter as a separate model would make a simulation faster without changing the way that the users write their code.