Minor code improvements in `PicaDecoder`.

Fixed a typo in the javadoc of th class and changed the name of a
private method to a better one.
Improved code formatting and added documentation.

Brought the formatting of the code in the metamorph package in line with
the rest of metafacture-core. Additionally, the javadoc comments were
improved and misleading comments removed.
Refactored the code for building pipelines in Metamorph

In the original implementation of Metamorph `Data` and `Collect` objects
managed the plumbing of their function pipelines internally (via
`AbstractNamedValuePipeHead`). From the perspective of the
`MorphBuilder` `Data` and `Collect` objects were connected directly. The
fact that the connection was actually done through the function pipeline
was hidden. While this approach simplified the `MorphBuilder`, it
increased the complexity of the interfaces for connecting the different
types of objects in Metamorph. Additionally, functions were required to
handle the source parameter in the `receive` method differently compared
to the implementations of the method in `Data` or `Collect` objects.
Finally, it the half-hidden implementation of the function pipelines
makes it very hard to add interceptors (e.g. for logging or debugging)
to the pipe system generated from a Metamorph script.

This commit tries to solve the short-comings of the original
implementation with to changes. First, connections of `Function`, `Data`
and `Collect` objects are now handled in the same way and the function
pipelines are no longer hidden in the other two objects. Second, the
objects are no longer connected to a receiver (via
`setNamedValueReceiver`) but the connection is set the other way round
using `addNamedValueSource`. While this approach appears slightly less
intutive than the original method, it removes the necessity for
calling `addNamedValueSource` in addition to `setNamedValueReceiver`.
Furthermore it unifies setting of an object as name source or
condition source and setting an object as standard data source. This is
now all done from the perspective of the receiver. This simplifies the
implementation of the relevant methods in the collectors.
Added source file location annotations to Metamorph DOM.

When debugging Metamorph scripts it is helpful to be able to link the
data, collector and function objects with their definition in the
Metamorph script. This commit annotates the XML DOM that is used to
build the actual metamorph object structure with location information
about location of each node in the source XML file.

The location information is attached as user data to element nodes using
the key `http://culturegraph.org/mf/user_data/location` (available via
`Location.USER_DATA_ID`). It contains start and end positions of the
element in the source file.

Implementing this functionality required a complete rewrite of the
`DOMLoader` because location information is only available from the SAX
parser and not from the DOM builder. Therefore the, implementation
uses a `Transformer` to construct a DOM from SAX events. The idea for
this implementation comes from
http://javacoalface.blogspot.de/2011/04/line-and-column-numbers-in-xml-dom.html

In the process of reimplementing the `DOMLoader` it was decided to move
the class and its helper classes out of the morph package and into its
own utility package due to the number of classes. Since we now have a
`util.xml` package the old `XMLUtil` class was moved into this package
as well.

Note: The default SAX implementation used by OpenJDK 1.7.0.60 includes
an old version of Xerces-J (2.7.1) which does not report location
information in x-included files correctly. A bug report for updating the
implementation exists (see https://bugs.openjdk.java.net/browse/JDK-8038043).
However, until this makes it into OpenJDK a newer version of Xerces needs
to be added manually to the classpath.
Refactored code for loading morph scripts.

In order to be able to include source file names in the location
information (see commit e10de395592d082596354646e555083e4aa5e1e6) the
XML input source needs to have the system id set to the file name of the
source file. This happens only if the `InputSource` object is
constructed from a URL. However, the old code for loading morph scripts
used `Reader`s or `InputStream`s for constructing the `InputSource`.

This commits rewrites the loading mechanism so that it works with URLs
instead of streams. Additionally, the number of `walk` methods in
`AbstractMetamorphDomWalker` are significantly reduced by moving the
creation of the `InputSource` to the `Metamorph` class.
Added source location infos to the morph pipeline.

Commit e10de395592d082596354646e555083e4aa5e1e6 annotated the Metamorph
DOM with information about the location of each element in the source
file. This commit adds this information to the data, collector and
function objects which are created based on the morph pipeline described
by the DOM.

The location information is made available through a new interface
called `KnowsSourceLocation`. It offers methods for setting and getting
location information from an object. `NamedValueReceiver` and
`NamedValueSource` extend this interface. The location information is
set via a setter method instead of via the constructor to avoid having
to add a constructor to every concrete collector or function class.
Simplified from interface `NamedValueSource`.

Changed the return value of `setNamedValueReceiver` in
`NamedValueSource` to void because it was not used anywhere.
Consequently, the type of the method parameter does no longer need to be
a generic and is changed to `NameValueReceiver`.
Add a system for interception to Metamorph

Currently, there is no way expect for using a Java debugger to find out
how data is processed by a Metamorph script. This makes introspection of
Metamorph scripts rather difficult as in-depth knowledge of the Java
implementation of Metamorph is required. Additionally, no simple method
exists for tools building on Metamorph (such as script editors) to
interact with Metamorph scripts during their execution.

This commit solves these problems by modifying the Metamorph
implementation so that the user can add user-defined interceptor objects
to the processing pipeline constructed from a Metamorph script. The
interceptor objects are added before and after each processing step in
the script. Additionally, the user can introspect the `flushWith`-
mechanism. It is up to the implementor of the interceptor objects
whether invokations are simply watched (e.g. for logging) or actively
interfered with (e.g. for setting break points to interrupt data
processing at certain points).

The implementation of the interception system is based on factory
classes which create the interceptor objects. The interface for these
classes is defined in `InterceptorFactory`. Users can implement this
interface to create custom interceptor objects. Instances of an
interceptor factory implementation can be passed to the `Metamorph`
object during its construction. The factory is internally passed to the
`MorphBuilder` which is modified to add an interceptor object into each
link between data-elements, functions and collectors. It also wraps
every flush listener in an interceptor object.

The interceptor factory can return `null` when asked for creating an
interceptor. The `NullInterceptorFactory` implements this behaviour and
serves as a default implementation of `InterceptorFactory` which
creates a Metamorph pipeline without any interceptors.

Writing an interceptor factory is quite simple. First, we need to
implement the actual interceptor objects; then we only need to create
and return instances of these interceptors in the factory class. The
following example demonstrates how to implement interceptors which log
all data processed by Metamorph to standard out:

  - The pipeline interceptors need to implement `NamedValuePipe`.
    However, we do not implement this interface directly but use
    `AbstractNamedValuePipe` as a base class. This class implements the
    method required for connecting the named value pipe with the
    pipeline so that we only have to implement the `receive` method
    which is called whenever data is passed through the pipeline. In
    this method we output the received data to standard out and pass the
    data to the next pipeline element (if we did not do this we would
    interrupt the pipeline):

    ```
    class NamedValueLogger extends AbstractNamedValuePipe {

        @Override
        public void receive(final String name, final String value,
                final NamedValueSource source, final int recordCount,
                final int entityCount) {

            System.out.println(name + ": " + value);

            getNamedValueReceiver().receive(name, value, this,
                    recordCount, entityCount);
        }
    }
    ```

  - The `flushWith`-interceptors need to implement `FlushListener`.
    Interceptors for flush listeners wrap the actual flush listener.
    We pass the original flush listener as a constructor argument to
    our interceptor:

    ```
    class FlushLogger implements FlushListener {

        private static FlushListener wrappedListener;

        public FlushLogger(final FlushListener wrappedListener) {
            this.wrappedListener = wrappedListener;
        }

        @Override
        public void flush(final int recordCount,
                final int entityCount) {

            System.out.println("Flushing: " +
                    wrappedListener.toString());

            wrappedListener.flush(recordCount, entityCount);
        }
    }
    ```

  - Now we need to write an interceptor factory for creating our
    interceptor objects:

    ```
    class LoggingInterceptorFactory implements InterceptorFactory {

        @Override
        public NamedValuePipe createNamedValueInterceptor() {
            return new NamedValueLogger();
        }

        @Override
        public FlushListener createFlushInterceptor(
                final FlushListener listener) {
            return new FlushLogger(listener);
        }

    }
    ```

  - To use our interceptors we need to pass an instance of our factory
    class to `Metamorph`:

    ```
    final InterceptorFactory factory = new LoggingInterceptorFactory();
    final Metamorph metamorph
            = new Metamorph("morph-script.xml", factory);
    ```
Removed old merge conflict in commit.

The javadoc of the `DefaultErrorHandler` had a merge conflict in the
javadoc of the class, which was not noticed and solved during an earlier
merge.
Merge branch 'master' into metamorph-interception

Prepare branch for reintegration into master. Resolves conflicts in
  src/main/java/org/culturegraph/mf/morph/AbstractMetamorphDomWalker.java
  src/main/java/org/culturegraph/mf/morph/MorphBuilder.java
  src/main/java/org/culturegraph/mf/morph/maps/JndiSqlMap.java
Merge branch 'metamorph-interception'

Modifies Metamorph so that interceptors can be added to a Metamorph
pipeline. The primary motivation for adding this was to enable tools
such as debuggers to inspect and interact with a running Metamorph
script. To further support such applications the elements in the
pipeline are annotated with their position in the XML source file.

In order to prepare for the rather large changes on the implementation,
work on the feature started with a clean-up of the Metafacture sources.

This merge contains the following commits:
  - Removed old merge conflict in commit
  - Add a system for interception to Metamorph
  - Simplified from interface `NamedValueSource`
  - Added source location infos to the morph pipeline
  - Refactored code for loading morph scripts
  - Added source file location annotations to Metamorph DOM
  - Refactored the code for building pipelines in Metamorph
  - Improved code formatting and added documentation
  - Minor code improvements in `PicaDecoder`