Come up with long-term approach to exposing `copy(...)` method in binding classes

[krzema12]

Kotlin 2.0.20 compiler started producing warnings if the primary constructor of a data class is private: https://kotlinlang.org/docs/whatsnew2020.html#data-class-copy-function-to-have-the-same-visibility-as-constructor

As a short-term approach, we just suppress the warning, and the customers get a warning on the call site which is independent of this library. However, we'd like to keep exposing this method, so let's discuss what options we have to choose once starting using Kotlin 2.1.0.

Discussion: https://kotlinlang.slack.com/archives/C02UUATR7RC/p1724584851609139

[krzema12]

Let's see if someone has some interesting take on this: https://kotlinlang.slack.com/archives/C8C4JTXR7/p1729233924861659

[krzema12]

Here's an idea: let's have a copy DSL, like added in krzema12/snakeyaml-engine-kmp#593. Then, we could make the binding classes not data classes. This approach is also safe in terms of binary compatibility.

[Vampire]

This approach is also safe in terms of binary compatibility.

If you mean it is binary compatible to the currently generated classes, then the this would be bad actually.
As I already explained in the comments in the PR I wrote for this.
That the newly generated code is a breaking change is intentional to improve the API, make the usage safer, and get to the originally intended situation because of which data classes were added in the first place.

I'm also not sure why we need a KSP to generate code into classes that we already generate when we can simply adapt the generation to generate what we want to have.