Replace attribute constraint strategy subclasses with model-driven attribute bindings

[jonathanvdc]

Problem

AttributeConstraintCodeStrategy centralizes attribute special cases, but it still hardcodes the supported universe in generator code. The long-term goal is to remove those generator-side subclasses and drive attribute behavior from ODS/imported model metadata.

This issue intentionally chooses the long-term plan directly: move from strategy classes as behavior containers to model-driven attribute binding metadata.

Current Hotspots

• src/MLIR.Generators/AttributeConstraintCodeStrategy.cs
• src/MLIR.Generators/DialectSymbolResolver.cs
• src/MLIR.Generators/Emitters/AttributeConstraintEmitter.cs
• src/MLIR.Generators/Emitters/Operations/OperationMemberPlanner.cs
• src/MLIR.Generators/Emitters/Operations/OperationAttributeValueHelpers.cs

Proposed Direction

Introduce an ODS/model-level binding concept for attribute constraints. A possible shape:

public sealed class AttributeConstraintBindingModel
{
    public string PublicType { get; }
    public string? StorageType { get; }
    public string? AssemblyFormatType { get; }
    public CodeTemplate? DecodeExpression { get; }
    public CodeTemplate? EncodeExpression { get; }
    public OptionalAttributeRepresentation OptionalRepresentation { get; }
    public AttributeCollectionShape CollectionShape { get; }
    public bool IsGenericTypedArrayElement { get; }
}

Populate this model from real ODS information plus MLIR.NET extension records in the prelude.

Acceptance Criteria

• Generator code no longer has one subclass per attribute constraint kind.
• Attribute constraint behavior is represented in MLIR.ODS model data or a similarly early layer.
• Existing supported constraints keep working: boolean, integer, float, string, opaque, elements, dictionary, type, unit, dense arrays, enum, and typed array.
• Unknown or unsupported constraints still degrade to a safe generic AttributeValue representation.
• The public generated operation property types remain stable unless a deliberate migration is documented.

Suggested Tests

• Generator tests for every currently supported AttributeConstraintKind.
• Typed-array tests with primitive, dictionary, type, elements, and unknown element constraints.
• Runtime print/bind tests for attributes that rely on custom assembly formats.

Migration Notes

A temporary adapter from the new binding model to the existing strategy API is acceptable only as an intermediate step. The completed issue should leave emitters consuming binding models directly, not dispatching through hardcoded subclasses.