fix: build Redline native memory layouts once

[Phoenixxo]

NativeMemory was building a new little-endian layout with withOrder on every read and write. Each new layout has no cached var handle, so every access had to look one up again through the JDK's var handle cache, and since the layout is never a constant the JIT can't turn the access into a plain memory read. Same kind of issue as #226 but for NativeMemory.

This builds the int, long and short layouts once as static constants and uses them for every access instead of building a new layout for each call. Floats and doubles already go through the int and long paths and bytes use JAVA_BYTE, so that covers the whole class. Byte order, alignment and bounds checks don't change, and the existing runner tests cover these paths.

NativeMemory is how Java reads and writes a Redline guest's memory, so any host moving data across the boundary hits this on every call. I found it in a while developing my Minecraft client mod for Wasm components. On Redline, a minimap mod copying a few hundred records in and out of guest memory every tick went from 72 µs to 24.3 µs per tick.

[andreaTP]

Thanks LGTM, while reviewing I found some other issues to be solved.
I'll follow up with another PR.