Fix locking in fallback atomics

[andreas-karlsson]

Follow-up to #224. While looking at the ByteArrayMemory fallback paths on JDK 25 I found three bugs in how atomics lock. Each bug has a new test in MemoryTest that fails before the fix.

1. Atomics on non-shared memory trapped. waitStates was only created for shared memories, so the lock-based fallback threw an NPE that surfaced as an out-of-bounds trap. Atomics are valid on non-shared memories, so the map is now always created. I chose that over skipping the lock so that atomics never silently stop being atomic. Note: for consistency the same fix is applied to ByteBufferMemory.

2. Overlapping atomics of different sizes didn't exclude each other. The lock was keyed by the exact address, so e.g. an i32 add at 0 and an i16 add at 2 took different locks and could lose updates. Both memories now lock the containing 8-byte word. Wasm atomics are naturally aligned and at most 8 bytes wide, so overlapping accesses always share a lock. This also affects ByteBufferMemory on every JDK, since it always uses the lock-based default atomics.

3. Lock-free and locked atomics were mixed. On JDK 25 the byte-array view handles lose their atomic modes, but byte atomics, which use an array element handle, keep them. Byte ops then ran lock-free while wider overlapping ops locked, so the locked read-modify-write could overwrite the byte update. A single LOCK_FREE flag now decides for all sizes and all atomic accesses (reads, writes and read-modify-write): either everything uses hardware atomics or everything locks. On JDK 21 nothing changes. On JDK 25 byte atomics now lock too, which costs some speed but is correct.

[andreaTP]

LGTM, thanks!