Make WrapDynaClass instance cache thread-safe (1.X)

[rootvector2]

Port of #418 to the 1.X branch.

WrapDynaClass.createDynaClass reads and populates its per-classloader cache through an unsynchronized get/create/put over a plain WeakHashMap, so threads that share a context classloader can corrupt the map and receive distinct WrapDynaClass instances for one key. Unlike master there is no atomic computeIfAbsent to lean on here (WeakFastHashMap inherits HashMap.computeIfAbsent, which bypasses its delegate map), so the port swaps the cache to BeanUtils.createCache() — the synchronized weak-keyed WeakFastHashMap that MethodUtils already uses — and synchronizes the get/create/put sequence on the cache so one key yields one instance. Includes the regression test from #418: it races 16 threads on createDynaClass for one bean class over 200 rounds; it fails on unmodified 1.X (two distinct instances for one key) and passes with the change.

Same caveat as #416: the full default goal hits one failure in LocaleBeanificationTest.testContextClassloaderIndependence on my machine, but it fails identically on unmodified 1.X and passes standalone, so it is pre-existing and unrelated to this change.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Hi @rootvector2
Note that this test is now broken. Please review ASAP.
https://github.com/apache/commons-beanutils/actions/runs/29845745287/job/88685774320

[INFO] Running org.apache.commons.beanutils.WrapDynaClassTest
Error:  Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.031 s <<< FAILURE! -- in org.apache.commons.beanutils.WrapDynaClassTest
Error:  org.apache.commons.beanutils.WrapDynaClassTest.testConcurrentCreateDynaClassReturnsSameInstance -- Time elapsed: 0.023 s <<< FAILURE!
org.opentest4j.AssertionFailedError: createDynaClass returned more than one instance for one key ==> expected: <1> but was: <2>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:563)
	at org.apache.commons.beanutils.WrapDynaClassTest.testConcurrentCreateDynaClassReturnsSameInstance(WrapDynaClassTest.java:84)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at java.util.ArrayList.forEach(ArrayList.java:1259)
	at java.util.ArrayList.forEach(ArrayList.java:1259)

[rootvector2]

Looked into it. The synchronization here is fine; the test asserted more than the weak cache guarantees. The CacheKey is only reachable through the weak-keyed cache, so a GC landing inside a round evicts the fresh entry and a late thread legitimately builds a second instance. Reproduces single threaded on unmodified 1.X: createDynaClass, then System.gc(), then createDynaClass returns a distinct instance. Master doesn't hit this because the beanutils2 cache holds soft references, which survive ordinary GCs. Fix is in #425: each round only asserts when a WeakReference canary shows no GC ran during it, so the race check stays (still fails on the pre-#419 code) but GC evictions no longer trip it. Verified it passes under a System.gc() hammer that made the old test fail with exactly the CI error. Sorry for the noise, and thanks for merging this one.