Reduce probability of breaking binary compatibility - stop using data classes in public API

[mateuszkwiecinski]

Expected Behavior

As per https://kotlinlang.org/docs/jvm-api-guidelines-backward-compatibility.html#don-t-use-data-classes-in-an-api data classes aren't recommended to be used in public library API, since they can easily lead to breaking binary compatibility.

Related issues:

• Is there a way to break API less often? #1975
• Add binary-compatibility-validator #2111

Current Behavior

data classes are used in the public api, which may have impact on post-1.0 binary compatibility

Additional information

I'm creating this issue as a result of this comment.

[mateuszkwiecinski]

https://github.com/drewhamilton/Poko could be helpful for classes like LintError or KtlintCliError where the customequals/hashCode (and toString?) are part of the public api

[paul-dingemans]

data classes are used in the public api, which may have impact on post-1.0 binary compatibility

I prefer that this is resolved before of at latest in the 1.0 version of ktlint. If needed, I am willing to consider to release a 0.51.0 version of ktlint and defer the 1.0 release.