ClassUtils: use context class loader by default

The loadClass method was using Class.forName, but using
Thread.currentThread().getContextClassLoader() is generally better, so
we do that instead.
ClassUtils: eliminate repeated code

The hasClass method was doing the same thing as loadClass (i.e.,
actually loading the class). So instead, we just delegate.
PluginInfo: allow specifying a custom class loader

It is now possible to pass a class loader explicitly to the PluginInfo
constructor, which will later be used when lazily loading the class.

This is important because it is not enough to use the default class
loader, or even the current thread's context class loader at the time of
lazy instantiation. Instead, we need the class loader that *was* the
relevant one at the time the class name was discovered (i.e., at the
time the PluginInfo was created).
DefaultPluginFinder: always specify the class loader

Previously, in the default case we relied on SezPoz to choose an
appropriate class loader. While it did make an appropriate choice (the
current thread's context class loader), we did not explicitly have a
guarantee that that's what it did. So instead, we explicitly manage our
own class loader instance so that we can always hand it off to the new
PluginInfo instances for later use. In this way, if the context class
loader later changes, the PluginInfo won't care, and will still do the
right thing at the time PluginInfo#loadClass() is called.
Merge branch 'class-loaders'

This branch fixes some issues with class loading during plugin
discovery. In particular, it ensures that when PluginInfos are created,
they remember the relevant class loader for later use during lazy class
loading (which can be deferred an indefinite amount of time).