Avoid the need for -H:+ForeignAPISupport

[JaroslavTulach]

Pull Request Description

Modifies #13206 to not need +H:ForeignAPISupport by alternatively using UnmanagedMemory and ByteBuffer on each side of the Channel.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.

[github-actions]

✨ GUI Checks Results

Summary

• 🧹 Prettier: ✅ Passed
• 🧰 GUI Checks: ❌ Failed
• 📚 Storybook: ❌ Failed

⚠️ Action Required: Please review the failed checks and fix them before merging.

See individual check results for more details.

[hubertp]

Could we potentially detect the unsupported platform and leave the old support, if we feel that it looks/is less complex? It certainly feels less hacky than using ByteBuffers.

And when GraalVM 25.x lands, we could easily go back to the previous implementation.

[JaroslavTulach]

Things seem to work on Mac Arm now:

sbt:enso> os-environment/test

passes.

[JaroslavTulach]

Could we potentially detect the unsupported platform and leave the old support, if we feel that it looks/is less complex?

• the good thing on the previous version was that MemorySegment was available in both SVM and HotSpot JVM mode
• this is no longer true, only ByteBuffer is available on both JVMs
• as such changes like 435d196 are necessary

It certainly feels less hacky than using ByteBuffers.

• it is not that bad
• one just has to remember to allocate native memory with UnmanagedMemory on the SVM side
• otherwise MemorySegment is 1:1 with direct ByteBuffer