feat[cartesian]: IntEnum support

[FlorianDeconinck]

Description

We introduced the (strict) support for IntEnum in code and arguments of stencils. The strategy is to replace them with proper integer as soon as possible.

Guardrails exists for name clash and IntEnum derivation.

Valid code looks like this

@gtscript.enum
class LocalEnum(IntEnum):
    A = 42
    B = 1000

@gtscript.stencil
def enum(field: gtscript.Field[float], order: LocalEnum):  # type: ignore
    with computation(PARALLEL), interval(0, 1):
        if order > LocalEnum.A:
            field[0, 0, 0] = LocalEnum.B

TO CLEAN

• Register of Enum types should not leave in gtscript
• ADR
• Mixed precision

Requirements

• All fixes and/or new features come with corresponding tests.
• Important design decisions have been documented in the appropriate ADR inside the docs/development/ADRs/ folder.

[twicki]

I think this works and makes for some centralization!

[FlorianDeconinck]

I don't like that ENUM_REGISTER is on gtscript, I will probably move it into it's own little space

[romanc]

I think this looks good as proof of concept. Some suggested wording changes inline.

[FlorianDeconinck]

Test fails on 3.10, fine on 3.11. Looks like the AST parsing of Enum has moved

[FlorianDeconinck]

Test will be happy when #2326 is in

[romanc]

That won't work with the per-stencil overrides of literal_integer_precision that we allow. In the GTScriptParser, you have access to the BuildOptions in self.options which contains literal_integer_precision. Likewise, in annotate_definition() of the StencilObject you get the BuildOptions as function argument, so you can get the precision from there.