consider using the forein linker api

The choosen binding approach: "Zippers are implemented by accessing internal TreeSitter data structures directly using sun.misc.Unsafe instrinsics and don't do any JNI calls and don't consume any additional off-heap memory."
seems good, however I recently read a comment from the panama lead architect about the performance of the new forein linker API
https://github.com/bytedeco/javacpp/issues/453

> Performance-wise, while the foreign linker does not speed up calls from Java to native, compared with JNI (**), there are some cases in which the new API fares quite well, and that's when native function accept/return parameter by value. In such cases, depending on how return/pass by value is emulated in JNI, the difference with the Foreign Linker API (which supports passing by value natively) can be non-negligible.

> (**) in case of back to back native calls, or calls to native code that is very short-lived, the Foreign Linker API supports an invocation mode which avoids Java to native state transitions, which can be useful to reduce latency (but should be used with caution, as it has the potential to crash the VM - e.g. if the function calls back to Java). We are also investigating optimizations for upcalls (e.g. from native back to Java), and we're more confident there that there is more room for improvement (the code to go from Java to native is well optimized in JNI, but the same cannot be said for the other way around).

I have no idea if this could improve performance with the bindings but that might be worth exploring.

finally, a fourth way of implementing efficient ? bindings might be to use graalVM internally for Intellij and to leverage the fascinating transparant interoperability it give between java/kotlin and C through Sulong
Also I believe that using graalVM Enterprise Edition for intellij would yield easy and potentially significant performance wins ([as can be seen here](https://plokhotnyuk.github.io/jsoniter-scala/) for example