Work around version skews with XML libraries

Sometimes (I am looking at you, OME!), obsolete XML components are
shipped as part of an OMERO-insight installation, intended to support
Java 1.5 which does not have its own XML libraries).

When multiple projects do that (I am looking at you, Batik!), the
XML components can easily cause trouble when the order of the individual
.jar files cannot guarantee that an appropriate xalan/xerces pairings
is discovered via the class path.

Now, in this time and age, Java 6 is thankfully common enough that we
can always fall back to the XML library contained in the JRE. Which
is exactly what this workaround is all about.

Jan Eglinger was very helpful in diagnosing the issue that he reported
in http://fiji.sc/bugzilla/show_bug.cgi?id=749.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Help debugging XML issues

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge branch 'xml-woes'

This topic branch adds a rather ugly, but required, work-around when
3rd-party libraries provide XML components that can easily lead to
class path problems when processing XML data via XPath. The symptom
is invariable an exception with a trace like this one:

> java.lang.NoSuchMethodError: org.apache.xpath.XPathContext.<init>(Z)V
>	at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207)
>	at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281)
>	at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:371)
>	at org.scijava.util.XML.<init>(XML.java:141)
>	[...]

Such errors are caused by whatever implementation of the XPathFactory
finds to be claiming the DocumentBuilderFactoryImpl service in the
corresponding META-INF/services/.

For example, the Batik component in Fiji ships a part of xalan (which is
actually not needed for Java 1.6 and later, because Xalan is now bundled
with Java), and likewise does OMERO insight ship xalan, but an
*incompatible* version of it.

As a work-around, we use the fact that the XPathFactory asks the current
thread's context class loader to discover the services. If it discovers
a non-functional XPath implementation, we set the context class loader
to the parent class loader until we find a working XPath implementation.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>