Do not register class-cached FFIType memory with Cleaner

[arimu1]

Summary

• FFIType descriptors for Structure classes are cached in typeInfoMap with Class keys so native ffi_cif pointers stay valid. That cache is intentional (storeTypeInfo already comments "prevent premature GC") and matches what FFITypes for non-base classes are never removed from typeInfoMap, causing the Cleaner thread to loop forever #1633 described; a Closeable/try-with-resources rewrite was rejected as too much API impact.
• The cached backing Memory was still registered with the JNA Cleaner. Application classes never unload, so those MemoryDisposer entries never drained and the cleaner thread looped (TIMED_WAITING / RUNNABLE after Structure instances were gone).
• Allocate that class-lifetime storage with TypeInfoMemory (no-arg Memory constructor: no Cleaner registration). Same FFIType layout and typeInfoMap cache as before.

Fixes #1633

Test plan

• HEAD d036ad9 proved the leak: Structure-backed FFIType used AutoAllocated + Memory, both with cleanable != null.
• After the change: TypeInfoMemory for both the FFIType struct and elements, cleanable == null; cache still returns the same pointer after the Structure instance is dropped.
• ant -D-native=true test -Dtests.include=com/sun/jna/FFITypeTest.java — 3/3 on Temurin 21 / darwin-aarch64 (testStructureFfiTypeDoesNotRegisterCleaner, testFfiTypeSizeMatchesStructure, testStructureFfiTypeRemainsCachedAfterInstanceGc).
• Native.initialize_ffi_type still accepts the cached descriptor (size matches the Structure).

[matthiasblaesing]

The core point here is this assumption:

Application classes never unload

On what basis is this claimed? Please have a look at this demo project:

UnloadableClassTest.zip

There are two classes in the project:

• DemoClass.java: This class is loaded with a custom classloader
• UnloadableClassTest.java: This is the Test that shall be run

After unzipping the project can be run as:

mvn process-classes exec:java

from the project directory.

The output will be:

Classloader of DemoClass: java.net.URLClassLoader@3b8aea15
==================================================
Demo ran
==================================================
Cleaning clazz
Cleaning classloader

What is happening here is:

• a cleaner is created
• runTest creates a new classloader (cl) based on the url derived from the class file of the UnloadableClassTest class
• the class loader is created without a delegate, so it will load the classes itself
• the DemoData class is loaded
• both the classloader and the class are registered with the cleaner with runnables, that will yield a message once the cleaner for these objects is invoked
• the classloader that actually loaded DemoData is printed (line one in the output)
• an instance of the DemoData class is created and its run method is invoked (this prints the "Demo ran") line
• System.gc is invoked in a loop. Once GC happens the "Cleaning ..." messages are created by the cleaner that runs the cleanup methods registered for the DemoData-Classloader and class