refactor: remove Kotlin runtime dependency

[lunaynx]

This was made by Codex using gpt-5.5 high. I've runtime tested it minimally on SkyHanni 1.21.11 and it seems to work fine, but it should be tested more before merging.

Some minimal call-site adjustments will be required on the consumer side, such as no longer being able to call MoulConfig's methods with named arguments.

[lineargraph]

will look at this later. for now a thought experiment: i should diff out the generated bytecode modulo some trivial patterns. feels like something that can be hacked together using javap and 50 or so lines of bash. maybe ill ask my AI, but it sounds fun enough that i might do it myself.

[lineargraph]

also noted: i want some kotlin specific functionality (specifically delegates) to still exist, but thanks anyway

[lineargraph]

also noted: i want some kotlin specific functionality (specifically delegates) to still exist, but thanks anyway

[lineargraph]

git show HEAD --name-only | grep \\.java | while read fn ; do git diff HEAD:$fn v4:${fn%.java}.kt; done

[lunaynx]

It seems like it deleted the KDocs? That's not ideal...

Edit: Should be fixed.

[lineargraph]

while some of the classes seem fine, the gradle script just makes me not super confident for the rest. ill try to do some post processing to make kotlin not a dependency instead and do incremental source code changes. but this is an interesting exercise.

[lineargraph]

like the simpler classes look fine but for the rest im just not sure. id rather just stick it out.

[lunaynx]

It's fine, you can take whichever parts you want, or don't. I don't even need this personally, since I generally develop/use Kotlin mods anyway. It just seemed to work well so I thought it may be useful.

[lineargraph]

i would like a pure java moulconfig a lot actually, i just feel like writing a somewhat reasonable runtime dep stripper is more reasonable than having AI translate everything automatically. some smaller more scoped rewrites also make more sense.

[lunaynx]

I don't know how much you can do that, it would probably be some really janky code if you continued writing Kotlin code but avoided any reliance on the stdlib.