[KDF] Add compatible @DataSchema interfaces as marker supertypes

Proof of concept for Kotlin/dataframe#2097. Today a schema declared
as a @DataSchema interface can only be used as a DataFrame argument
after an explicit cast, even when the inferred schema of the frame
already satisfies the interface. That makes it impossible to write
reusable extensions such as
`fun DataFrame<UserLike>.nameAndAge(): String` and call them on a
frame built by dataFrameOf without losing the generated accessors.

FunctionCallTransformer generates two local classes per refined call:
a schema class holding the columns and a marker class extending it,
used as the DataFrame/DataRow type argument. Since both containers
are covariant in that parameter, adding an interface as a supertype
of the marker is enough to make extensions on the interface resolve.
The new PolymorphicDataSchemasService collects the @DataSchema
interfaces of the module via a lookup predicate, turns each into a
PluginDataFrameSchema and matches it against the schema inferred for
the call: every column of the interface must exist at the same path,
with the same column kind and a subtype-compatible type, while extra
columns are ignored. Matches that are already implied by another
match are dropped, so `UserLike : Named` contributes `UserLike` only.

Supertypes are added to the final marker only, not to the schema
class or the nested group schemas behind it, and candidates are
limited to non-generic interfaces of the module being compiled. Both
restrictions keep the number of generated supertypes bounded, as
suggested in the issue.

The feature changes call resolution for existing code, so it is
gated behind a -P plugin option (polymorphicDataSchemas) and, in
tests, behind the POLYMORPHIC_DATA_SCHEMAS directive. It is off by
default.

Box tests cover DataFrame and DataRow receivers, rows passed as
arguments, markers produced by chained refined calls and a schema
hierarchy with several simultaneous matches. Diagnostic tests pin
down the generated supertypes in the FIR dump, the cases that must
not match (missing column, wrong type, wrong nullability, wrong
column kind) and the fact that nothing changes with the option off.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>