Resource interface class may not be found

**Describe the bug**
When running in an OSGI environment, the TCCL may have access to a component, but the component might be accessing a resource implementing an interface to which the TCCL has no access.

**Expected behavior**
If the interface class cannot be looked up through the usual path (TCCL, extension classloader), also try the classloader of the resource itself.

```
try {
String name = aDependencies[i].getInterfaceName();
if (name != null && name.length() > 0) {
>> Class theInterface = loadUserClass(name); // <= this may only be available through the resourceClass'es classloader

>> Class resourceClass = getResourceClass(qname); // <= this may be available
if (!theInterface.isAssignableFrom(resourceClass)) {
throw new ResourceInitializationException(
ResourceInitializationException.RESOURCE_DOES_NOT_IMPLEMENT_INTERFACE,
new Object[] { qname, aDependencies[i].getInterfaceName(),
aDependencies[i].getSourceUrlString() });
}
}
} catch (ClassNotFoundException e) {
throw new ResourceInitializationException(ResourceInitializationException.CLASS_NOT_FOUND,
new Object[] { aDependencies[i].getInterfaceName(),
aDependencies[i].getSourceUrlString() });
}
```

**Please complete the following information:**
- Version: 3.2.0

Locate the resource-loading path containing loadUserClass(name) and getResourceClass(qname), then reproduce or trace the OSGI classloader case described in the issue. Verify the usual lookup failure and resource classloader fallback, along with the existing assignability and class-not-found error behavior, before running the relevant resource initialization tests.

Written by the indexing model from the issue text.