Migrate Win32Handler to Java's new Foreign Function & Memory API

[HannesWell]

Migrate the Win32Handler off JNA and to the Java Foreign Function & Memory (FFM) API.
The FFM bindings are generated by jextract using the script added with this change.

Currently this contains TODOs that have to be resolved before this is submitted.

[github-actions]

Test Results

    54 files  ±0      54 suites  ±0   57m 13s ⏱️ -28s
 4 810 tests ±0   4 788 ✅ ±0   22 💤 ±0  0 ❌ ±0 
12 321 runs  ±0  12 168 ✅ ±0  153 💤 ±0  0 ❌ ±0 

Results for commit f07b368. ± Comparison against base commit aa2fb6d.

♻️ This comment has been updated with latest results.

[vogella]

Thanks for working on this @HannesWell I would like to look into the Linux side, so I suggest to move the BREE change out into an independent PR so that you can work on the Win side and I can work on the Linux side. I think only the BREE is actually overlapping for this. work.

[HannesWell]

I would like to look into the Linux side, so I suggest to move the BREE change out into an independent PR so that you can work on the Win side and I can work on the Linux side. I think only the BREE is actually overlapping for this. work.

Yes, my plan was also to look at the Linux side subsequently.
But it was not only to convert the existing JNI bindings to FFM but to also move those parts that don't require own native code anymore to use Java NIO instead. See for that the discussion in #302 (comment) ff.
Furthermore I think it would be good to use again a tool to generate the binding deterministically, like jextract, and just let AI generate some bindings.
If you want to work on that, that's ok for me and I don't think updating the BREE change has to be separated. It can be done in any change and whichever is first, is first.

[vogella]

@HannesWell will you also address Mac OS?

[HannesWell]

will you also address Mac OS?

For the file-system, macOS should be 'handled' by

• Replace native UnixFileHandler by Java NIO to fetch/put file-info #2925