Separate classloader leak tests from the 'all' tests

The classloader leak unit tests may generate enough garbage to fill 99.9% of free memory if there is a leak or if some SoftReference prevents collection of the classloader for a while. The memory is released as part of the test (which includes System.gc() calls in finally blocks to make sure the gc runs to clean it up before the next test.) Still, filling the heap like that is potentially disruptive to the VM, so these tests should be separated into their own test run, segregated from the main 'all' tests.