Add opt-in StrongEnums mode for strongly typed protobuf enums

[wasimat404]

This PR adds an opt-in mode where protobuf enums are treated as their own types instead of plain integers. It follows the direction described in #450, where strongly typed enums with explicit conversions were mentioned as the long term goal. Also related to #815.

What it does when the option is enabled:

• Enum constants like GlobalEnum.GAZ evaluate to a value of the enum's own type, and type() returns the fully qualified enum type.
• Reading an enum field from a message gives an enum typed value. This also works for default values and for numbers that have no declared name.
• Equality checks both the enum type and the number. An enum value is never equal to a plain int or to a value of a different enum type.
• Conversions are explicit. int(e) gives the underlying number. Each enum type can be called as a conversion function: MyEnum(n) accepts any number that fits in int32 (an error otherwise), and MyEnum('NAME') looks up the value by name (an error if the name does not exist).
• The type checker agrees with all of the above, and message construction accepts enum typed values.
• Works the same for proto2 and proto3.

The mode is off by default. Nothing changes for existing users. It can be enabled with cel.StrongEnums(true) or through config files with the feature name cel.feature.strong_enums.

How it is built:

A new Enum value type carries the enum type name and the int32 number. The registry gets a strongEnums flag (same pattern as JSONFieldNames), and when it is on, EnumValue, FindIdent and field access return enum typed values. The checker takes the constant type from the value the provider returns instead of always using int, so legacy behavior is untouched when the flag is off. The conversion functions are registered as normal function declarations per enum type, so both checked and parse-only programs can use them.

Tests cover literals, type(), equality, field selection (defaults and unnamed numbers), conversions with range and name errors, message construction, parse-only evaluation, checker output types, and the legacy default, for both proto2 and proto3. All existing tests pass.

I am happy to adjust naming, the option surface, or the checker wiring if you prefer a different design.

[TristonianJones]

/gcbrun