Prevents jvm incompat dataclass constructors with value class params

[jackcviers]

• To prevent issues like RequestConfig not constructable from other jvm languages #275, dataclasses must not use parameters
  that are value classes without a JvmStatic factory method in their
  companion object.

[raulraja]

Thank you, Jack!

After looking over the files, it seems at first sight all issues here are related to the use of the value class.
If that is the case we need a rule to disallow using value classes.
I think the rule for static companion factories is unnecessary, and in main, we now have instances of multiple cases where the Prompt class, a data class, is called from Java to any of its constructors.

Can we have a single rule to disallow value instead of 2 rules?

[jackcviers]

Thank you, Jack!

After looking over the files, it seems at first sight all issues here are related to the use of the value class.
If that is the case we need a rule to disallow using value classes.
I think the rule for static companion factories is unnecessary, and in main, we now have instances of multiple cases where the Prompt class, a data class, is called from Java to any of its constructors.

Can we have a single rule to disallow value instead of 2 rules?

We can. It would also result in a change to RequestConfig that would not be source compatible, if that's acceptable. My intention with these lints is to be as non-invasive as possible to the declared api to avoid disruption of the current pace of development.

If we don't mind me changing the signature of RequestConfig and potentially call sites (I think 11, currently), the current two Lint riles can be collapsed to a single rule disallowin value classes in common and jvm source sets. I can address this very quickly, just give me a 👍 on this comment.

It should be noted, if the concern is additional rules, we will need additional rules anyway:

Ok. So action item out of this is --

Lint rule for no value classes in common/jvm.
Lint rule for jvm overloads with constructor args on data classes.

In addition we need rules for avoiding the creation of public common and jvm apis relying on kotlin annotations, which cannot be called as annotations from scala. We can achieve the same effect by declaring jvm annotations in a Java class for the jvm, and platform specific annotations and processors can be declared for the other multiplatform source sets. Currently, only Description.kt and JsonSchema.kt and the @Description (17 call sites) will require changes.

Finally, I intend to ensure all platforms have equivalent examples, which may reveal additional required lint rules.

[raulraja]

We can make those changes to RequestConfig. We are currently ongoing heavy API changes to simplify the library.
The reality is that having used value classes has introduced more issues than benefits, and the code we have to add to work around them is higher than the benefit of saving an allocation.

[raulraja]

thank you Jack!