Support a ClassLoader when instantiating handlers

When configuring the handlers chain for a given IdP or SP we need to support a different ClassLoader from where a specific handler class should be loaded from.

Today we always load a handler class from the classloader used to load the picketlink jar classes or from TCCL. See org.picketlink.identity.federation.core.saml.v2.util.HandlerUtil.

It is important to improve how handler classes are loaded so we can load them from different places. A driven use case for that is when you are using the subsystem to configure the handler chain, where handle classes can be in a user-defined static module in EAP or WildFly.