HSEARCH-1122 Update Avro dependency to 1.6.3
HSEARCH-1115 Changed use of ReflectHelper to specify classloader

Two uses of ReflectHelper.classForName(String) were changed to use the
classForName(String,Class) form instead. In the latter method, if
the class cannot be found on the thread's context class loader then the
class will be loaded using the classloader of the class specified in
the second parameter.

In one of the cases (DocumentBuilderHelper), the DocumentBuilderHelper class
was passed, meaning that the same classloader used to load the Hibernate Search
classes will be used.

In the second case (ConfigContext), the second parameter is the class of
the SearchConfiguration implementation that was supplied to the ConfigContext.
This is better than the ConfigContext class, since the SearchConfiguration
implementation will be provided by the components using the SearchFactoryBuilder
to build a SearchFactory. This means that the components' classloader
will be used to load the Analyzer implementation class.

There are a few other uses of ReflectionHelper.classForName(String) in the Hibernate
Search codebase, but I don't think they require the same classloading logic.

When used in a Java SE environment, there is no net difference in classloading
behavior. However, in JBoss AS7 (or even OSGi) the different classloaders have
a significant effect. Specifically, when used in JBoss AS7, the modules might look
like this (where "-->" signifies 'depends on'):

  org.foo (uses Hibernate Search, implements SearchConfiguration)
   --> org.hibernate.search.engine
       --> org.hibernate (specifically the hibernate-commons-annotations JAR)
       --> org.apache.lucene
       --> others

In this case, the result of the code before this change is that ConfigContext
would expect to find the Analyzer implementation using the 'org.hibernate'
module (where the ReflectHelper class exists), which does cannot see any of
the 'org.apache.lucene' Analyzer implementations nor any implementations
provided by 'org.foo'. After this change, ConfigContext uses 'org.foo' classloader
(since that's where the SearchConfiguration class exists), and thus can see
any Analyzer implementation provide in 'org.foo', 'org.hibernate.search.engine',
'org.apache.lucene', 'org.hibernate' (if there were any), or any of the other
modules.

All unit tests run by the build pass successfully with these changes.
HSEARCH-1115 Avoid reflection when we have the data and pass the right caller for modular environments

Since ReflectHelper is in Commons Annotations which depends on nothing, it's critical
to provider the right caller
HSEARCH-1115 Make sure to load Hibernate / JPA exceptions with the "best" classloader

commons-annotations is not the correct classloader in a modular environment
HSEARCH-1115 Doing all class loading via ClassLoaderHelper. Also doing moving the classForName methods from commons annotations into ClassLoaderHelper.
HSEARCH-1115 Fixing some typos in log method names
HSEARCH-1115 ClassLoaderHelper#classForName takes now the classloader as second parameter instead of the caller class

Re-added the explicit passing of the caller's classloader to ConfigContext and DocumentBuilderHelper
HSEARCH-1115 Avoid holding on foreign classloader from LoaderHelper