RAM Support

XLS should have special support for RAMs (I'll write RAM in most places, but note that usually these will be SRAMs). In particular:

1) There should be a collection of useful RAM models. Currently, an abstract RAM model and a single-port RAM model exist. This should be augmented with multi-port models, as well as models that encapsulate initialization (e.g. a proc that wraps an uninitialized RAM with a state machine that writes initial values into the memory upon startup).
- These RAM models enable native (and fast, via the JIT) testing of blocks that use RAMs.
- RAM models are currently written in DSLX, but nothing prevents them from being written in HLS C++ (or via C++ builders).
2) There should be a pass that lowers more abstract RAM variants into lower RAM variants, e.g. abstract RAM -> 1RW RAM.
3) There is a codegen option that writes RTL to drive lowered RAMs (currently, only 1RW). Without this option, the channels to the RAM models will be codegen'd as normal ready/valid/data channels. With the codegen option, it will instead spit out separate `addr`, `wr_data`, `we`, `re`, etc. signals. This codegen option should be expanded to support more RAM variants when they are added.
4) There should be automation to manage relevant metadata for all these steps. For example, the xlscc frontend will take as input a configuration describing the abstract memory (depth, width, etc.). From the frontend, IR optimization and codegen need metadata to describe how to lower the RAMs (e.g. lower to 1RW RAM with 1 cycle latency). For now, it seems that the frontend can produce metadata for each downstream step.

The lowering pass consists of the following steps:

1. Generates (from DSLX, or HLS C++, or whatever) a new IR-level proc that models a lowered version of an existing RAM.
2. Adds the new IR into the existing package.
3. Rewrites `send/receive`s from the old proc model's channels to the new proc model's channels. This will likely consist of some tuple packing and unpacking[^1]. Abstract RAM operations need to be scheduled onto lowered RAM ports (this scheduling is trivial for single-port RAMs. Initially, greedily scheduling seems useful for many applications, but this is a rich area for optimization.

Some Milestones:

- [ ] Models
- [x] 1RW model
- [ ] 1R1W model
- [ ] 2RW model
- [ ] Codegen
- [x] 1RW Codegen
- [x] 1R1W Codegen
- [ ] 2RW Codegen
- [ ] Abstract -> Concrete Lowering
- [x] Abstract -> 1RW
- [x] Abstract -> 1R1W
- [ ] Abstract -> 2RW
- [x] Support masked writes (and reads?) through codegen
- [ ] Put metadata in IR
- [ ] Model generation (or have frontend always generate model proc)
- [ ] IR label for behavioral funcs/procs (do not inline)

[^1]: It is possible that this rewritting could be complicated for some memories, but it seems like is better to put any tricky mapping of abstract->concrete operations into a wrapper proc. The wrapper can be inlined/multi-proc codegen'd, leaving a lowered RAM while keeping the pass simple.