Negedge-triggered SRAMs

We currently have `SeqMem` as a primitive for posedge-triggered SRAM; I would like to get people's thoughts on adding a corresponding primitive for negedge-clock-triggered SRAM.

This request may require negedge registers too, since it is common to flop the output of SRAM immediately. Perhaps optionally rolling the output flops into the NegSeqMem will be decent approach? Example: `SeqMem(n, w, latency=1, negedge=true)`.

-------

* **Type of issue**
- [ ] Bug report
- [x] Feature request
- [ ] Other enhancement

* **What is the use case for changing the behavior?**

Very clever designs can shave off a pipeline stage by having some logic trigger on the negative clock edge. For example, accessing an SRAM that is indexed by a hash function:

Posedge logic pipeline:

Cycle1: compute hash; send idx to SRAM
Cycle2: access SRAM; flop output because no time is left after cycle-long access.
Cycle3: do stuff with data

Negedge logic:

Cycle1-hi: compute hash; send idx to SRAM
Cycle1-lo: access SRAM; flop output after cycle-long access
Cycle2-lo: do stuff with data

* **Impact**
- [ ] no functional change
- [x] API addition (no impact on existing code)
- [ ] API modification
- [x] unknown

* **Development Phase**
- [x] request
- [ ] proposal

* **Other information**

Here is the current workflow to effect this behavior:

* create a module with asynchronous-read memory
* Pad out with a register to effect the 1-cycle latency
* Blackbox/manually drop in neg-edge SRAM when performing actual ASIC design

I'd like to believe we can model negedge triggered memories in a way that doesn't blow up our ecosystem, like chisel-testers or FIRRTL compiler passes, but still provide a comfortable path to optimal ASIC designs. The closer the Chisel-generated behavioral module is to what the blackboxed implementation would be, the lower the design risk will be.

Start by reviewing the existing SeqMem primitive and the FIRRTL compiler passes and chisel-testers mentioned in the request. Define how a negedge-triggered memory and optional output flops should fit the API, then verify that generated behavior remains compatible with the ecosystem and supports the described ASIC workflow.

Written by the indexing model from the issue text.