[HW][CAPI] Add a function to get an empty InnerSymAttr

[SpriteOvO]

This allows us to set sym for partial ports - something like this pseudo-code:

mlirOperationSetInherentAttributeByName(
    moduleOp, // The module has 3 ports created
    "portSyms",
    mlirArrayAttrGet({ hwInnerSymAttrGetEmpty(ctx), hwInnerSymAttrGet("name"), hwInnerSymAttrGetEmpty(ctx) })
);

[dobios]

I can see how this can be useful, and I'm guessing it is to you if you're making this PR so LGTM!

[dtzSiFive]

I don't have bandwidth so don't mean to interfere without helping fix things 😉 but probably this suggests a better API would be useful, so the whole "set empty if any are non-empty" stuff doesn't propagate across the C API too 😞 .

Although I think the philosophy of the C api might be to be super simple and direct, which the above might violate.

But regardless it is what it is presently.

On that -- is there any use for setting inner symbols on specific fields, or only the entire "thing" (fieldid=0)?
Sincerely curious, and in part asking because empty could be an inner symbol with no "fieldid/name" pairs (visibility is there too but welp) included or something. Maybe? 😄 .

[SpriteOvO]

On that -- is there any use for setting inner symbols on specific fields, or only the entire "thing" (fieldid=0)? Sincerely curious, and in part asking because empty could be an inner symbol with no "fieldid/name" pairs (visibility is there too but welp) included or something. Maybe? 😄 .

So far, we only used inner_sym when emitting firrtl.ref.rwprobe from Chisel (code), and from my understanding, it's cleanest to set inner_sym only when needed (see #6524 for the reason). So when firrtl.ref.rwprobe references a port, we only set inner_sym for that port. And to align the portSyms array with the ports array, we need empty InnerSymAttrs to populate the unused/unreferenced ports in the portSyms array.

Honestly, for field I'm not sure there are some use cases.

[sequencer]

Although I think the philosophy of the C api might be to be super simple and direct, which the above might violate.

We noticed it, basically the C-API we added here is only intended to Build the MLIR Module from Java Binding, in the future, it may be used by other bindings or even a new DSL construction flow, but for now, the only consumer is the Chisel panamabinding framework.

the panamabinding framework aims to eliminate the serialization in Chisel and parse in firtool to speed up the elaboration time, and possibly remove the code duplication in the future: we only need to maintain the ser/deser in CIRCT, and LLVM/MLIR provide a good infrastructure for us.