Fix a ClassNotFoundException raised during demarshalling

Fix a ClassNotFoundException raised during demarshalling

Under certain conditions an error like:

Caused by: java.lang.ClassNotFoundException: org.opendaylight.controller.sal.reader.FlowOnNode
	at org.eclipse.gemini.web.tomcat.internal.loading.BundleWebappClassLoader.loadClass(BundleWebappClassLoader.java:312) ~[na:na]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ~[na:1.7.0_09]
	at java.lang.Class.forName0(Native Method) ~[na:1.7.0_09]
	at java.lang.Class.forName(Class.java:264) ~[na:1.7.0_09]
	at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135) ~[na:na]
	at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116) ~[na:na]
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:893) ~[na:na]
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205) ~[na:na]
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) ~[na:na]
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) ~[na:na]

this is due to the fact that by default the Jboss Marshaller used by
Infinispan uses the Thread Context Class Loader to retrieve the
classloader to be used in the demarshalling function. Equinox provides
a default one
(org.eclipse.core.runtime.internal.adaptor.ContextFinder) as TCCL,
however it heuristically try to find the classloader and in some cases
can fetch the wrong one. Now given that all the classes managed by
clustering services must go via OSGi it make sense to force the usage
of only the bundle class loader and we let OSGi framework to figure
out how to load the class.

Change-Id: I24a9056eda5f6ab7b8cf0ab2e476be56cb61f6c1
Signed-off-by: Giovanni Meo <gmeo@cisco.com>