Add @TableSource for dense test matrices

[em3s]

Summary

Adds @TableSource, a second YAML-based data source for @ObjectSourceParameterizedTest. It accepts a columns header and rows list so dense primitive matrices keep CSV-like density while staying pure YAML and sharing the same name-based parameter binding as @ObjectSource.

Why not just keep @CsvSource?

@CsvSource is a fine tool and for a single file often looks slightly more concise than @TableSource. The reason we are introducing @TableSource is not density — it is type-processing consistency.

Every data-driven test in the project should flow through the same pipeline:

• One parser (ObjectMappers.YAML, Jackson) for all parameterized data.
• One place to register custom domain-type deserializers — state machines, event types, storage handles — and have them work everywhere.
• One null marker (~), one boolean convention, one nested-object story.

@CsvSource uses a separate conversion pipeline (JUnit's ArgumentConverter), which silently pushes string→domain conversion into test bodies. Today in this repo that shows up as ad-hoc helpers like toBooleanFlexible(), toStateValue(), handleSpecialValue(), toEventType(), toEventSequence() inside state transition tests — every file re-implements the same CSV-string-to-domain-type coercion. With @TableSource (and a Jackson module registered for the domain types) those helpers become unnecessary: YAML values are already typed when the test body runs.

The density argument alone does not justify a new annotation. The unified type pipeline does: one change in one module picks up custom types for every data-driven test, and test bodies stop repeating string-parsing adapters.

Shape comparison, for reference:

// @CsvSource — dense, but each file must convert strings to domain types
@ParameterizedTest
@CsvSource(
    "IDLE,    START, RUNNING",
    "RUNNING, STOP,  IDLE",
)
fun test(from: State, event: Event, expected: State) { ... }

// @TableSource — +1 line, but shares @ObjectSource's Jackson pipeline
@ObjectSourceParameterizedTest
@TableSource("""
    columns: [from, event, expected]
    rows:
      - [IDLE,    START, RUNNING]
      - [RUNNING, STOP,  IDLE]
""")
fun test(from: State, event: Event, expected: State) { ... }

Changes

• New: TableSource annotation (core/src/testFixtures/.../params/TableSource.kt).
• Modified: ObjectSourceExtension now dispatches on whichever annotation is present; existing @ObjectSource behavior is unchanged.
• Docs: TESTING.md gets a short "Dense matrices" subsection explaining the split.
• Tests: TableSourceTest covers columns/rows expansion, ~ → null, enum binding, and @Nested classes.

This PR is purely additive — no rename, no existing class moved. If we want to rename ObjectSourceExtension to something more neutral now that it handles both sources, that can land as a separate rename-only PR (100% similarity, blame survives squash merge).

Test plan

• ./gradlew :core:test --tests '*TableSourceTest' --tests '*ObjectSourceTest' green
• ./gradlew :core:test full suite green
• Documentation example paths exist
• CI checks pass (CodeQL, Analyze, submit-gradle, CLA)

Out of scope

• Migration of existing @CsvSource / @MethodSource tests (tracked in Migrate 33 Kotlin data-driven tests to @ObjectSource #271). Adopting @TableSource is what unlocks removing the string-parsing helpers in state transition tests.
• Jackson module registration for specific domain types (State, StateValue, EventType, ...). That will happen alongside the first migration PR that needs it — there is no need to over-engineer upfront.
• Rename of ObjectSourceExtension to a neutral name. Separate PR from the original author.
• Java support. @ObjectSource/@TableSource are both Kotlin-only today; extending to Java requires enabling -parameters project-wide and a Java-reflection fallback.