In-jvm dtest to detect InstanceClassLoaderLeaks

It is currently very easy to add dependencies/code that cause in-jvm dtest InstanceClassLoader leaks, and hard to find them. These patches add a WeakHashSet that allows us to count the number of reachable InstanceClassLoaders in the in-jvm dtest API, so that we can use it in the ResourceLeakTest in the actual Cassandra branches in CI (it only takes 2 iterations to find the leak recently introduced by the inclusion of the oshi.jna  library, which was fixed in https://github.com/apache/cassandra-in-jvm-dtest-api/pull/38)

Notes:

The trunk patch requires the changes made in the in-jvm-dtest-api project in order to compile.

Additionally, ResourceLeakTest#looperEverythingTest (the newly-enabled test) won't fail once we pick up the changes made to include `osha.jna` in the in-jvm-dtest-api project, so I added some "DO NOT COMMIT" code there to prove the test can in fact detect the leak.

NOTE: I'm removing the `DO NOT COMMIT` code that demonstrates the test actually fails when there's a leak. If you want to try it out, you can change the line 202 in ResourceLeakTest.java to this: 

            try (Cluster cluster = (Cluster) builder.withNodes(numClusterNodes).withConfig(updater)
                    .withSharedClasses(builder.getSharedClasses().and(name -> !name.startsWith("oshi.jna.")))
                    .start())

This removes the `oshi.jna` classes from the shared class loader, which demonstrates the failure.