DERBY-6619 After silently swallowing SecurityExceptions, Derby can leak class loaders

Patch derby-6619-2.

The fix introduced in DERBY-3745 correctly is there in order to
protect against the case where the thread that starts Derby, has a
context class loader that is different from the system class
loader. In such cases, if the timer thread inherits the context class
loader, the context class loader will stay in memory until the Derby
engine is shut down, even if all other references to the class loader
are gone.

If the context class loader is the same as the system class loader, on
the other hand, such a "leak" would not be a problem, since the system
class loader will stay in memory until the JVM is shut down anyway.

We take advantage of this and only attempt to change the context class
loader if it is different from the system class loader.  With this
patch, no warning is printed to derby.log when starting the server
from the command line, and there's no warning when starting the server
using the API with a security manager installed when the context class
loader hasn't been changed from the default. However, if the server is
started using the API with a non-default context class loader, we do
see warnings in derby.log if a security manager is installed and the
permission to set the class loader is missing.

Added tests for this behavior. Moved utility methods from
UpgradeClassLoader to ClassLoaderTestSetup, a new decorator. It seemed
more logical to put them there to allow reuse.

git-svn-id: https://svn.apache.org/repos/asf/db/derby/code/trunk@1620379 13f79535-47bb-0310-9956-ffa450edef68