UV3 refactor class loading for consistency / maintainability

There are 4 main places the UIMA framework loads classes: the Framework itself at startup, Resources, Annotators (a kind of resource) and JCas Classes. The last 3 can make use of UIMA extension class loaders, or PEAR isolation class loaders.

Refactor the code to have these where possible use common code.

One issue to confirm: the current code uses 2 methods for loading classes:
Class.forName and classloader.loadClass. The Class.forName has a variant which takes 3 arguments, making it functionally equivalent to the loadClass. But its operation is subtly different in that it caches the reference to the loaded class, even if it isn't the defining class loader, whereas loadClass doesn't do this. See http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html for a discussion of this, and the comments for a reply from Oracle tech support saying:

Applications should basically never call Classloader.loadClass(). It may appear to work but it is often subtly wrong, can be a source of latent bugs, and is almost never the best choice. They should instead call Class.forName() using the 3 parameter version that takes a specific Classloader instance.

Our current code always (I think) uses Class.forName for the case where there is no UIMA class loader, and loadClass otherwise. I think this would cause failures in an OSGi loading scenario, where one of the parent loaders was an OSGi loader and it dynamically switched its "parent". The expectation would be that the child loader (the UIMA class loader), the next time it was called to load something not in its set of classes, would delegate to the parent chain and the OSGi loader would now load from whatever was it's current "parent". But instead, because the UIMA loader would have "cached" the class, it would instead be stuck getting the old class forever (unless the old class was eventually GC'd)

Therefore, I think to work properly in this scenario, we must always use loadClass, and never Class.forName.

The one known issue of loading named arrays doesn't arise in our case, unless from some highly usual user code, and we can catch this and use Class.forName in this instance.