Promote parameter parser printer extractor escape hatches into structured bindings

[jonathanvdc]

Problem

Attr/type parameter behavior is currently driven by loose string escape hatches: csharpParser, csharpPrinter, csharpExtractor, csharpDefault, csharpType, and csharpSyntaxType. These are useful, but every emitter interprets them directly and slightly differently.

The generator should consume a structured parameter binding model instead of scattering textual substitution logic through type and attribute assembly-format emitters.

Current Hotspots

• src/MLIR.Generators/Emitters/AssemblyFormat/AttributeAssemblyFormatEmitter.cs
• src/MLIR.Generators/Emitters/AssemblyFormat/TypeAssemblyFormatEmitter.cs
• src/MLIR.ODS importer code that populates AttrOrTypeParameterModel
• Prelude extension records that define C# parser/printer/extractor metadata

Proposed Direction

Introduce a structured ParameterBindingModel, for example:

public sealed class ParameterBindingModel
{
    public string PublicType { get; }
    public string SyntaxType { get; }
    public SyntaxValueShape SyntaxShape { get; }
    public CodeTemplate? Parse { get; }
    public CodeTemplate? Bind { get; }
    public CodeTemplate? Print { get; }
    public CodeTemplate? Default { get; }
}

The importer should convert existing extension fields into this binding model once. Emitters should ask the binding to emit parse, bind, print, and default expressions.

Acceptance Criteria

• Type and attribute assembly-format emitters no longer directly inspect all Csharp* parameter fields.
• Existing prelude extension metadata still works through the new binding model.
• Missing bind/default behavior still produces a clear generated exception or diagnostic with owner and parameter names.
• The same binding model is usable by both type and attribute assembly-format emitters.
• Documentation or comments explain the expected placeholder substitutions in CodeTemplate values.

Suggested Tests

• Parameter with custom parser only.
• Parameter with custom parser plus extractor.
• Parameter with custom printer.
• Parameter with default value.
• Self type parameter for attributes.
• Negative test for a parameter that lacks extractor and default metadata.

Notes

This is closely related to the SyntaxValueShape issue and should either depend on it or introduce enough shape metadata to make that issue straightforward.