Avoid using data classes in the API

[3flex]

I noticed that the API makes liberal use of Kotlin data classes. This is discouraged for libraries:

• https://kotlinlang.org/docs/api-guidelines-backward-compatibility.html#avoid-using-data-classes-in-your-api
• https://jakewharton.com/public-api-challenges-in-kotlin/

I suggest removing data classes from the public API. If any of those classes still require equals, hashCode and toString implementations the Poko compiler plugin can generate those by adding a simple annotation to classes that require it.

I would be happy to work on a PR for this but given it would be a breaking change I'm not sure if this should be parked until a possible v2 release or if it could be done as part of v1.6.

[nielsvanvelzen]

This is definitely something to consider changing in a future release, and I have thought about it before. Fortunately, we have our own code generator so we can extend that to generate the hashCode/toString functions. The only problem will be in the copy function where we can't keep compatibility.