Experimental: JDK 22 Foreign API

[CedNaru]

Not meant to be merged.
This is purely to make my tests using the new JDK foreign API more visible.

I didn't convert the whole codebase to the new API. I simply replace our two most important calls in the module
The KtFunction::invoke used when Godot calls scripts methods like process or enter_tree and the TransferContext::icall used for any call to the Godot API.

Regarding the results I don't have good new:
I ran our worst and best bunnymark on both master and this branch using the official Hotspot 22 build.

• C++ to JVM Bunnymark: 29k --> 22k. We actually lose performances.
• JVM to C++ Bunnymark: 65k for both. The performances are unchanged.

Part of the loss in the slow bunny mark might be caused by the fact that so far I haven't found a way for the Foreign API to use JVM instances as parameters. It means that unlike with JNI, I have to retrieve the JVM wrapper/scripts by fetching the MemoryManager which involve hashmap reading and locks.

Another thing I noted. Even when running the master branch, the results are quite different from what was previously measured and recorded here : https://github.com/utopia-rise/godot-kotlin-jvm/tree/master/harness/bunnymark.
Those previous results were made 1 year ago, but I ran the bunnymark quite a lot this summer when working on the memory rework and the results remained mostly the same.

The only difference this time is that I used Hotspot 22 instead of Azul 17. I need more investigation, but it seems that hotspot is quite better for calls from C++ to JVM but worse for calls from the JVM to C++ (We gain 10K for our worse benchmark but lose 20K for our best). Maybe going from Godot 4.2 to 4.3 also had an effect, it's hard to tell.

But overall, as it is right now, the Foreign API is not worth it. And unlike what it says, it doesn't bring any extra security. The difference is mostly that the "binding code" is written in Java instead of C++ and that we use an API to defined function signatures instead of strings. But it's still as easy as before to have a mismatch between the C++ and JVM signatures.

This API seems to be really designed around using jextract on a C header and then use it alongside a dynamic library. But in the context of our project being C++ driven, I have yet to see the benefits, even from a maintainability point of view.
This API is still in preview and will evolve in future JDK version, so it might get better. On top of that, finding examples and tutorial is hard so far. I had to rely on minimal examples on the Oracle website and then just the raw API documentation, so I'm not sure if I'm using it correctly.