Dubious claim on long[]/double[] alignment in MemorySegment javadoc

MemorySegment Javadoc states, dubiously: "The starting physical address of a long[] array will be 4-byte aligned (e.g. 1004) on 32-bit platforms" (https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/MemorySegment.html#segment-alignment)

This is not true:

```
$ jdk21u-ea.32/bin/java -jar jol-cli.jar ...
# VM mode: 32 bits
# Compressed references (oops): not needed
# Compressed class pointers: not needed
# Object alignment: 8 bytes
# ref, bool, byte, char, shrt, int, flt, lng, dbl
# Field sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8
# Array base offsets: 12, 12, 12, 12, 12, 12, 12, 16, 16

[J object internals:
OFF SZ TYPE DESCRIPTION VALUE
  0 4 (object header: mark) 0x00000001 (non-biasable; age: 0)
  4 4 (object header: class) 0xa4f7e820
  8 4 (array length) 1
 12 4 (alignment/padding gap)
 16 8 long [J.<elements> N/A
Instance size: 24 bytes
Space losses: 4 bytes internal + 0 bytes external = 4 bytes total
```

If it was true, then AtomicLongArray would have broken: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java

I think there is a bit of confusion that non-atomic nature of long/double accesses has to do with alignment. It is, however, mostly about the size of the access. This is why AtomicLongArray works: it assumes that long[] are actually aligned by 8, and then do atomic accesses with extended memory ordering semantics on it.