Chisel Linker

Splitting Definition and Instance is what we all agreed for a long time. Currently we have a D/I API for it. However there still exist shortages:
- D/I only happens in the build time, doesn't support importing Verilog or FIRRTL.
- The macro usage make IDEA unhappy(at least in Jiuyang's team, we heavily use the IDEA as our main IDE)
- Parameterization is tricky for D/I.

The essential issue here is we still lack of the most important feature: serialization and deserialization for public module:

There are some premature solutions we have tried:
- `SerializableGeneartor` in Chisel to serialize generator itself.(it doesn't know the IO of FIRRTL)
- `firtool --scalarize-ext-modules --scalarize-public-modules`(but it cannot go back to Chisel)
- `firtool --chisel-interface-out-dir` is a Scala codegen for a public module.(I think this is dirty)
- `AutoBlackBox` via slang, see #2851

There are good but tries, but is not a SOTA solution:(

Thanks to @SpriteOvO. Chisel is able to parse FIRRTL or MLIRBC via new Panama CIRCT API. which may resolve the essential problem: How do we can eat back the elaborated FIRRTL, imported as Definition.

I'm proposing a new way for linking Modules in Chisel/MLIR, here is some limiation.
- Only `SerializableGeneartor` can be linked, since it provides a standard way for serialize and deserialize elaboration time parameter.
- Only public and scalarized module can be linked. since it's possible to get the base type.
- `SerializableParameter` should be stored in a special `Property`, telling chisel how to elaborate again for a reproducible build.
- Besides the Module name and IO, linking should also contain: `Probe`, `Property`.

Here are my ideas:
1. a `Declaration`(similar to `Instance[SomeModule]`, but manually defined by user) only provides the Interface. For the name of interface, it cannot be automatically renamed.
2. an `Implementation` can be a real Chisel `Module`, user just implement it, connect to the `Interface` on their own.
3. an `Implementation` can be a MLIR/Verilog `Blackbox`, Panama CIRCT should provide an API for importing corresponding files, automatically link to the Declaration.
4. Provide a reproducible build API: re-elaborate the `Implementation` imported from `BlackBox`, force `importing` and `exporting` to be strictly identical: one from Chisel Module, another one from imported MLIR.
5. At the CIRCT level, imported MLIR should live in its own namespace, For generated Verilog, it should live in a standalone compile unit.(I'm not sure if CIRCT support it, if not a prefix is another possible solution.