Motivation:

- Unnecessary JNI fallback
When `Unsafe` is disabled or unavailable, but the JDK provides a usable
FFM (Foreign Function & Memory) API, the existing code still falls back
to JNI to obtain the address of a direct `ByteBuffer`.

- Incorrect FFM semantics in `PlatformDependent0#directBufferAddress`
The `Unsafe` branch returns the **base address** of the direct buffer
(index 0), consistent with JNI `GetDirectBufferAddress`.
However, the FFM branch uses `MemorySegment.ofBuffer(buffer).address()`,
which effectively returns `baseAddress + position`.
This leads to inconsistent semantics between the FFM and Unsafe/JNI
implementations.

``` java
        ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1024);

        //ffm api
        System.out.println(PlatformDependent.directBufferAddress(byteBuffer));
        // jni
        System.out.println(Buffer.memoryAddress(byteBuffer));

        byteBuffer = byteBuffer.position(16);
        System.out.println(PlatformDependent.directBufferAddress(byteBuffer));
        System.out.println(Buffer.memoryAddress(byteBuffer));
```

On Java 25 and Netty 4.2.12.Final, this code prints:
```
129502193232224
129502193232224
129502193232240
129502193232224
```

The third line reflects baseAddress + 16, demonstrating that the FFM
path is position-dependent, while the JNI path remains
position-independent.

Modification:

- Prefer the FFM/JVM path when `Unsafe` is unavailable but FFM is
available, avoiding the JNI fallback.
- Fix the FFM branch to return the same **base-address semantics** as
the Unsafe/JNI paths (i.e., position-independent).

Result:

 fix FFM address semantics in directBufferAddress

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
(cherry picked from commit b4c2ddb)