inverse location

Fixes #391

Fixes #391

Fixes #388

sources.jar

An archive for sources can be downloaded
directly from Gitlab, in pages related to
tags or releases.
Uses the standard maven source plugin instead
of rebuilding it with assembly.

A new method getAlgorithmId() gives the algorithm identifier (DUVENHAGE,
CONSTANT_ELEVATION_OVER_ELLIPSOID, ...)

Fixes #381

Internally, we really use Gradient as the implementation in the library,
and DerivativeStructure in the tests for cross checks.

Fixes #385.

Fixed issues #379 and #378

Direct location is performed in two phases, with a first intersection
being computed without corrections, then correction are applied and the
first solution is "refined". It was expected that the DEM cell did not
change there. Unfortunately, sometimes the refining did not find a
result in the same DEM cell. This was a very rare occurrence, and was
detected first on very ... rugged areas like mountains.

Now, when this rare event is detected, we restart a full-blown
intersection but starting from a point just after the exit of the
failing cell, when LOS is still above DEM and we prevent the algorithm
to find solutions backward (i.e. we prevent it from finding the previous
solution again and looping infinitely).

In the updateTile method (to be developed by the user according to the
kind of raster to be read), it happens that some useless data are
dumped. For instance, when reading some SRTM data, one needs to read
also some Geoid data. When reading the Geoid data, the elevations may be
dumped (if using the SimpleTile.interpolateElevation method).