Move JVM variant types and Set<Enum> registration to the new entry gen model.

[CedNaru]

The way we currently handle conversions for several types is not centralized in one place, is error-prone, and not other-JVM-language friendly.

The 2 main cases for that are the 32 bits version of Integer and FLoat, and the Enum<Set> as well Godot doesn't know these types, as the only things it can allow in the scripting API are the different Variant types. Only 64 bits Integer and Float are supported.

So far we cheated by adding an additional type to the Variant Enum here: https://github.com/utopia-rise/godot-kotlin-jvm/blob/33f74e84c55e0d40027345184212dd1b670e4c29/kt/godot-runtime/src/main/kotlin/godot/core/Variant.kt#L84

We created those types so we would be able to freely use Integer and floats of different sizes if needed. But in the end, they just wrap the "true" Godot type and define a conversion function to/from it.

The same can be said about the Set<Enum> properties. We create a specific function for that case in the registration code: https://github.com/utopia-rise/godot-kotlin-jvm/blob/33f74e84c55e0d40027345184212dd1b670e4c29/kt/godot-runtime/src/main/kotlin/godot/runtime/Registration.kt#L125

Obviously, Godot doesn't support bitflags this way, they are simply integers with each bit named.

In both cases, it was created just out of convenience to use/bypass Kotlin features/limitations.

My proposal is to get rid of those exceptions in the code and let the new EntryGen 2.0 model handle everything. That model is supposed to match the Godot Object model, not the Kotlin one. In both cases of a 32 bits Integer or Set<Enum>, Godot only knows about a regular 64 bits integer and so the Type stored inside the RegisteredProperty (New model class for properties) should also be that 64 bits integer.

To handle specific Kotlin or another language type, we can add to that RegisteredProperty class, a pair of lambda to convert from/to that specific type.

Example: In the case of the enumSet, it up to the Kotlin symbol processor to identify this case, create an Int-based RegisteredProperty, and add a function to convert it back to a Set of Enum using the ordinal to the power of 2.

It's very similar to the pair of VariantType we already use to write/read to/from the native buffer. That proposal would basically add a second optional layer of conversion to add additional type on a per-language basis.

This would greatly simplify the first buffer-oriented layer and the Registration DSL as well.

Removing JVM_INT from the VariantType enum will also require a small change to the API generation. Currently, it's used to get the right enum from an ordinal sent by Godot, because ordinals are 32 bits and Godot return 64 bits, we use JVM_INT for the automatic conversion but it can easily be replaced by a direct cast.

[CedNaru]

Additional note:

The VariantMapper will also need to be split into 2 (one for the true Godot type, one for the custom) so we can also use those conversions with VarriantArray and Dictionnary. This will be added by configuration when the entry file is executed.