DroidGuard: Fix native library conflict on concurrent handle requests

[unpluggederan]

Cache the DexClassLoader instance statically so that concurrent DroidGuard handle requests for the same VM key reuse the same classloader instead of creating a new one that conflicts on the native library.

Without this fix, dual-SIM devices crash with UnsatisfiedLinkError when both SIMs trigger DroidGuard simultaneously (e.g. during RCS provisioning), because Android doesn't allow the same .so to be loaded by two different classloaders.

The loadClass() method does have synchronization and caching, but it doesn't quite cover this case.
classMap is per-instance, so a fresh HandleProxyFactory starts with an empty cache and won't find anything.
weakClassMap is static but it's a WeakHashMap, so the entry can get garbage collected between calls if nothing else holds a strong reference to the class
When both miss, a new DexClassLoader gets created for the same APK, and that's when Android complains about the native lib already being loaded. So the synchronization prevents them from running truly in parallel inside loadClass(), but the second caller still ends up creating a new classloader because neither cache reliably had the entry.

[mar-v-in]

The issue you are describing has effectively been resolved through #3239 (by caching the classes statically). I guess it appeared on a version of microG from before #3239 was merged.