Add dyn_mems as primitives

[nathanielnrn]

This adds dyn_mems which are like seq_mems but do not guarantee one-cycle read/write latencies. See #2105 for motivation.

One thing that's occurred to me is dyn_mem seems mainly useful as a placeholder for various implementations/connections to external memories. As in, if we need the guaranteed 1-cycle latency given by seq_mem we can rely on the seq_mem implementation.

The SystemVerilog dyn_mem implementation is exactly the same as the seq_mem implementation. So it seems that as a standalone primitive dyn_mem lacks utility. It seems like we could only add a "wrapper" of dyn_mem as a primitive without any actual implementation behind it. Maybe this is a can of worms not worth opening right now, as I don't know how happy the compiler would be with the possibility of "empty primitives." I'd be happy to hear thoughts people have on this.

Closes #2105

[rachitnigam]

#1151 is also related to this in case we want the compiler to decide the latency of the memories.

[sampsyo]

Thanks, @nathanielnrn, and thanks to @rachitnigam for calling up that extremely-relevant prior discussion. I am not exactly sure how to proceed on the larger question here—clearly, there is some real design work to be done for variable-latency memories (and other components). But for my money, I think we should probably just add this brute-force route as reflected in this PR now so we can make progress with the AXI business? Any objections to that as a short-term plan, @rachitnigam?

One reason to stick with this PR as it currently stands rather than making these dyn_mems "empty" as @nathanielnrn suggests:

It seems like we could only add a "wrapper" of dyn_mem as a primitive without any actual implementation behind it.

Is just so that we can actually execute programs as-is, without externalizing them. That is, even if it's impractical, it is nice to have a "shim" implementation of dyn_mem that has the same semantics as the more-realistic implementations.

[rachitnigam]

Seems fine to me! And yeah, I think the design of virtual operators is going to be important in the future so let's not rush it here.