[RTGTest] Add representation for immediates

[maerhart]

No description provided.

[darthscsi]

Is there a major reason to use this instead of wrapping an APInt?

[maerhart]

This is supported naturally by elaboration while just wrapping an APInt requires some more custom handling in elaboration and my goal is to avoid custom handling in elaboration when possible.

Basically, we need to know how to represent the elaborated version of the op and how to materialize it again.

• With this representation we can just store the constant folded attribute and then call the materializer of the dialect that defines the attribute.
• When using an APInt (i.e. IntegerAttr) we'd also need to store some additional information to know which materializer to call (e.g., the dialect of the operation that we got the folded value from and the type since the type stored in the IntegerAttr does not match the type we actually want (and was the return type of the constant op originally)). Depending on what information exactly we store additionally, we might have to internalize it in elaboration rather than storing it as a primitive value (if we just store the attribute and the type and assume that the dialect defining the type is the one with the materializer, it'd be 16 bytes and might still be fine as a primitive value).

To conclude, it's definitely possible to just wrap an APInt, but would that be more elegant than having a custom attribute? To me, this seemed more elegant, but let me know if you think otherwise.

Alternatively, it'd also be possible to just use the builtin integer type for immediates which wouldn't require any additional handling in elaboration and also avoids this entire PR, but then it's less clear when you want to define an immediate and when, e.g., an upper bound for an scf.for loop. It would mix meta and payload constructs.