Support mapped C# interface methods via TableGen extends overlays

[jonathanvdc]

Problem

Issue #155 introduced metadata-driven C# interface member mappings for MLIR interfaces, but the first implementation intentionally focused on property-style members only. That keeps the generator surface simple and works well for getter-like methods such as getElementType, hasRank, and getShape.

However, some useful MLIR interfaces expose meaningful method-shaped API that should remain methods in C# rather than being forced into properties or ignored entirely.

Today there is no overlay schema or generator support for projecting mapped C# methods with parameters onto generated interfaces and concrete generated TypeDef / AttrDef classes.

Proposed Change

Extend the MLIR.NET interface overlay schema and generator pipeline to support mapped C# methods.

This should include:

• a schema for method-shaped interface members, for example a MLIRNet_InterfaceMethod record alongside the existing property mapping support;
• importer support for method member metadata, including return type, member name, and parameter metadata;
• generator support to emit C# method signatures in generated partial interfaces;
• concrete implementation support so generated TypeDef / AttrDef classes can satisfy those methods either by:
  • reusing an already compatible generated member, or
  • emitting a method body from an explicit implementation expression/template;
• clear diagnostics when a mapped method-bearing interface is not fully implemented.

The design should remain metadata-driven and generic. No hard-coded branches for specific upstream interfaces.

Design Principles

• Keep upstream MLIR interface methods as provenance metadata; only explicitly mapped methods become C# surface API.
• Preserve the existing property-focused path for getter-like members.
• Support parameterized methods without attempting to parse or translate arbitrary C++ signatures automatically.
• Prefer explicit templates/expressions over heuristic translation.
• Preserve marker-only behavior for interfaces with no mapped members.

Open Design Questions

• What is the minimal parameter schema for mapped C# methods?
• Should explicit method implementations support statement bodies, expression bodies, or both?
• Should a generated property be allowed to satisfy a zero-argument getter method mapping, or should method/property compatibility remain strict?
• Should the first slice cover both TypeInterface and AttrInterface, or land on one first?

Out Of Scope

• Automatic translation of arbitrary upstream C++ method signatures.
• Operation interfaces.
• Runtime verification.
• Handwritten runtime types/attrs outside generated output.

Acceptance Criteria

• Add overlay schema records for mapped C# interface methods.
• Import mapped method metadata into the ODS model.
• Emit mapped methods in generated partial C# interfaces.
• Allow generated TypeDef / AttrDef classes to satisfy mapped methods through existing members or explicit implementation templates.
• Produce a clear diagnostic when a mapped method requirement is unsatisfied.
• Add focused importer and generator tests using a small local interface with at least one method parameter.
• Preserve existing property behavior and marker-only behavior for unaffected interfaces.