[FIRRTL] Add has_been_reset intrinsic

[fabianschuiki]

Add the circt.has_been_reset FIRRTL intrinsic. More specifically:

• Add the firrtl::HasBeenResetIntrinsicOp
• Add support for the op in the FIRRTL visitor
• Add support for the op in LowerIntrinsics
• Lower the op to verif::HasBeenResetOp, inferring the sync/async-ness from the reset's FIRRTL type
• Add tests for LowerIntrinsics, LowerToHW, and the canonicalizer
• Add a firtool end-to-end test to check that this interacts properly with the InferResets pass

[jackkoenig]

While I can't fully confirm that the C++ and Tablegen are correct, they pass the smell test and the tests definitely LGTM

[dtzSiFive]

LGTM!

[dtzSiFive]

Why does adding a FIRRTL op require adding headers to other dialects? Are these missing from the FIRRTL places, or unrelated?
(They appear necessary, but haven't looked at why, do you remember/know?)

[fabianschuiki]

I really don't get this part of TableGen. The key here is the include "mlir/Interfaces/InferTypeOpInterface.td" line in VerifOps.td. If you have an op with something like

let results = (outs I1:$result);

TableGen will only produce the implicit conversion from Op to Value and the builder function without the result TypeRange if you have the InferTypeOpInterface.td include further up in the TD file. If you comment out the include, the accessors and builders with inferred result type won't be generated. Even if your op doesn't implement or inherit from that InferTypeOpInterface at all. All that's needed is the include. Blows my mind.

So what ends up happening is I have something like that I1 result and expect it to work nicely, and won't realize I'm missing that include until I actually try to use that specific builder; which likely wasn't the case in the original PR that just added the op 🙈