feat: interaction builder dsl

[marcuscastelo]

This PR adds a command builder DSL

TODO:

• Base implementation
• KDoc
• Unit tests
• Example usage

[oglassdev]

Personally, I would extend SimpleBlockInteraction/SimpleInstantInteraction/etc and have like KytaleSimpleBlockInteraction with the executors properties in its constructor, then override Hytale's methods to call those.

If you'd like, I can write that up soon.

[marcuscastelo]

Personally, I would extend SimpleBlockInteraction/SimpleInstantInteraction/etc and have like KytaleSimpleBlockInteraction with the executors properties in its constructor, then override Hytale's methods to call those.

If you'd like, I can write that up soon.

You mean instead of undefined amounts of InteractionHolder being passed to the dsl builder constructor, we pass specialized classes for each interaction superclass (SimpleBlockInteraction/SimpleInstantInteraction/etc) that inherits them so the dsl builder remains clean without lots of params in its constructor?

From

@KytaleInteractionDsl
class KytaleSimpleInstantInteractionBuilder(
    codecBuilderScope: CodecBuilder<Interaction>,
    private var firstRunHolder: KyInteractionExecutorHolder<FirstRunExecutor>,
) : KytaleInteractionBuilder<Interaction>(codecBuilderScope) {
    fun firstRun(block: FirstRunExecutor) {
        firstRunHolder.executor = block
    }
}

To

@KytaleInteractionDsl
class KytaleSimpleInstantInteractionBuilder(
    codecBuilderScope: CodecBuilder<Interaction>,
    private var delegations: KySimpleInstantInteractionDelegations,
) : KytaleInteractionBuilder<Interaction>(codecBuilderScope) {
    fun firstRun(block: FirstRunExecutor) {
        delegations.firstRun = block
    }

   // More methods would not increase the builder param list
}

If so, I think it is a good idea, but those lambdas would still be necessary at those specialized classes, it would be nice if we could get rid of them too in some way or at least rid of the typealiases like FirstRunExecutor, etc. since they are not in sync with the superclasses and may mismatch silently in future updates, causing lots of headache with generic types and ambiguous signatures. That would require some way to reference a protected non-static method from SimpleInstantInteraction and "convert" it to a KFunction or FunctionN, and I don't know if it is possible

[marcuscastelo]

@oglassdev Something like this? 08e42a0