Serializable class hierarchy for statements, expressions and types

[csanadtelbisz]

Making the statements, expressions and types serializable. For this, the relevant classes were converted into Kotlin.

Important changes:

• The above classes are Kotlin data classes now that are serializable. Serialization is not automatic (it can only be automatic with sealed classes but we have expressions defined in different modules so this is not an option). A KSP task is introduced that automatically generates a serialization module containing serializers for the classes in the core module. These serialization modules (e.g., hu.bme.mit.theta.core.type.generated.expr.exprSerializerModule) can be used for serialization. Note that the serialization module has to be extended whenever a new expression/type is declared in a different (gradle project) module. See the core serialization module definition in SerializerModule.kt that can be included in extended module definitions.
• Hash codes and equals function implementations are removed from the above classes: they are replaced by the auto-generated ones for Kotlin data classes. The equals (and/or hashcode implementations) are preserved when it does not trivially compares the attributes (e.g., signedness is not considered in some classes). Declarations such as VarDecl or ParamDecl were only considered equal when we had the same references: since this is not representable in a serialized form of the instances, a new id attribute is added to Decl for the sole purpose of serialization. Do not use this id in other contexts.

[kris7t]

Does the migration of the Stmt and Expr classes from Java to Kotlin lead to API breakage in other branches, especially long-running ones? While this is not a blocker (although @leventeBajczi could probably provide more insight on the Theta API stability policy), it should be something we watch out for (and preferably document) to help us in future merges/rebases.

[csanadtelbisz]

Does the migration of the Stmt and Expr classes from Java to Kotlin lead to API breakage in other branches, especially long-running ones?

The only breaking changes that I am aware of (but they are not really changes in the API, rather consequences of Java-Kotlin conversion):

• All methods of a Kotlin object cannot be imported together with a *. So the used methods have to be manually listed. For example, see subprojects/cfa/cfa-analysis/src/main/kotlin/hu/bme/mit/theta/cfa/analysis/CfaToMonolithicExpr.kt#L35-L36 where the imports are expanded instead of simply importing import hu.bme.mit.theta.core.type.fptype.FpExprs.*
• Tuple2s are replaced by Kotlin Pair, but it can also be used from java
• Also, see the PR description for changes related to hash codes, but it should not cause any changes in how they behave

[leventeBajczi]

@csanadtelbisz, can you take a look at the conflicts?

[csanadtelbisz]

I think this is not a crucial change for sv-comp, and it brings many fundamental changes (mostly refactoring that affects the core of Theta). So I vote for postponing this PR after sv-comp to avoid a hurried merge.