JDKClassLoader could abort unnecessarily in the future

Right now, com.sun.corba.se.internal.util.JDKClassLoader is package private, and loadClass is only called from JDKBridge in that package.

JDKBridge always calls loadClass as

JDKClassLoader.loadClass(null, className);

so this bug doesn't actively cause problems.

If we use JDKClassLoader in the future and pass in a non-null Class, however, we must fix this:

If aClass is non-null in loadClass (and thus we try to load with aClass's ClassLoader), we

1) Don't need to search the call stack for the latest user defined loader

2) MUST cache the failure as a failure with the key {className, aClass.getClassLoader()} rather than using the latest user defined loader