Memory Intrinsic API

**Memory** is not SRAM only, they should also include, SRAM, ROM, RF

**Type of issue**: Feature Request

**Is your feature request related to a problem? Please describe.**
Chisel is using behavior memory since it was invented. However for all of the ASIC designs, the Memory IP is limited, even in FPGA, the choice of memory is also a big issue. designer is required to know what memory they are using before design, thus the current Mem/SyncMem API is quite anti-pattern for most of users: They define the memory, describe the memory behavior using `when` block, and let CIRCT infer which memory they are using. And most of user, including I have been struggling in frighting with it to generate the correct memory interface.

Thus I'm proposing adding a new Memory interface by directly define an memory `extmodule` with intrinsic, e.g. `class SRAM(nWord: Int, nBits: Int, replaceMacroname: String, ...)` it should directly generate `firrtl.mem` without any inference in CHIRRTL.

I do believe the currently memory behavior is harmful. Except senior engineer knowing how to define memory with the original API, I found most of newbies to chisel/RTL world are abusing it and think the memory can be abused like this.

Thus I propose after we finish the new Memory API, we should deprecate original API to make the chisel memory becoming reasonable.

**Describe the solution you'd like**

Here are my proposal:
1. Internal review on memory IPs from different Fabs and FPGAs, give a list of popular ASIC/FPGA memories compiler and those behavior.
2. Conclude a general API for these memories, including define ports with the attribute of `R`, `W`, `RW`, and hazard map.(We can provide another library to predefine it)
4. Implement the chisel frontend and CIRCT backend.
5. Deprecate Mem and SyncMem

There are a lot of other benefits: we can simply define RF/ROM as one of Memory intrinsic, we may have better API to define the preset of memory(for FPGA) and ROM(for rom compiler), RF can be also defined with it, currently most of users are using a RF Module, and replace them in the PnR flow.

No source files or tests are named. Start by reviewing the existing Mem and SyncMem APIs and the CHIRRTL-to-firrtl.mem flow, then map the proposed frontend and CIRCT backend changes. Done would require an agreed SRAM/ROM/RF memory API, implementation across those layers, and a decision on deprecating the existing APIs.

Written by the indexing model from the issue text.