Remove TraversePropertiesDsl from top-level toDataFrame {} operation

[Copilot]

Top-level preserve() / exclude() calls inside toDataFrame {} had broken semantics: they were supposed to apply to all properties {} blocks but did not work reliably, and calling them without any properties {} block produced an empty DataFrame. The compiler plugin also never supported this notation.

Changes

• CreateDataFrameDsl<T> no longer extends TraversePropertiesDsl — exclude() and preserve() are no longer directly available at the top level of toDataFrame {}
• CreateDataFrameDslImpl — removed TraversePropertiesDsl by configuration delegation
• Deprecated shims — exclude(), preserve(), and preserve<T>() are kept on CreateDataFrameDsl with DeprecationLevel.WARNING (→ ERROR in 1.1), forwarding to a properties {} block to ease migration
  ERROR, because their behavior is no longer possible, as the supertype of CreateDataFrameDsl was removed.
• Binary API — updated via apiDump; methods remain in bytecode for binary compatibility

Migration

// Before (broken — top-level preserve silently ignored without properties())
toDataFrame {
    preserve(DataFrame::class)
}

// Before (confusing — top-level preserve applied to all properties blocks)
toDataFrame {
    preserve(DataFrame::class)
    properties()
}

// After (correct)
toDataFrame {
    properties(maxDepth = Int.MAX_VALUE) {
        preserve(DataFrame::class)
    }
}

• Fixes Remove TraversePropertiesDsl from top-level toDataFrame {} operation #1857

[Jolanrensen]

Seems like a good base, I'll continue from this

[Jolanrensen]

@koperagen I added a DslMarker to prevent functions from toDataFrame {} being called from inside properties {}.
This simplifies the DSL somewhat.
I believe this doesn't have any negative effects, unless you can think of an example that seems legit but that I broke with this marker?

[koperagen]

@Jolanrensen good idea to add declarations for clear deprecation :)

@koperagen I added a DslMarker to prevent functions from toDataFrame {} being called from inside properties {}. This simplifies the DSL somewhat. I believe this doesn't have any negative effects, unless you can think of an example that seems legit but that I broke with this marker?

I don't see valid use cases that this marker could break.

[Jolanrensen]

good idea to add declarations for clear deprecation :)

Haha, props to copilot for that idea ;P

[koperagen]

good idea to add declarations for clear deprecation :)

Haha, props to copilot for that idea ;P

ahahahahaha
hold on
guess it's not funny then