Some breaking changes planned - feedback welcome

[atsushieno]

I have been stumbled upon some backward compatibility issues that I want to break (bring in breaking changes). I hope they are relatively minor issues, but need to be addressed and discussed before they actually take place. Feedbacks are welcome.

(1) Deprecating and removing rtmidi-javacpp: unlike our Panama-based binding (libremidi-panama), javacpp-based bindings involve native library resolution issue that we still need rtmidi .DLL/.dylib/.so installed locally. It is practically non-issue on alsa-javacpp (as libasound should be almost always there), rtmidi-javacpp remains problematic. Since libremidi-panama works fairly well and it covers MIDI 2.0 as well, I'm leaning towards simply removing rtmidi binding.

(2) ktmidi-ci (in)dependency: Currently ktmidi-ci module is independent of ktmidi because MIDI-CI is merely SysEx processing and transport agnostic. However we have a lot of utility functions and constants in ktmidi and I need them in ktmidi-ci if I want to move a handful of features in ktmidi-ci-tool that I believe are not specific to that particular application (e.g. MidiCIDeviceModel without Compose MutableState dependencies). The next version of ktmidi-ci will be dependent on ktmidi

(3) migration to Kotlin 2.1+ ABI: unlike migration to Kotlin 2.0, migration to Kotlin 2.1 involves ABI incompatibility, which means that apps whose codebase and/or its Gradle builds (including plugins) that have compatibility issue with Kotlin 2.1 ABI will be unable to upgrade to the newer version. It would have already happened who cannot depend on Java 22+ for Panama dependency, but (unlike Panama) we don't really need Kotlin 2.1+ features so far. But I will have more difficulty in updating dependency packages if I keep ABI backward compatibility (e.g. I cannot upgrade kotlinx-coroutines already).