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).

Issue #377
In case the dump is already suspended, the resume stage is dealt
correctly

correction

Issue #376

In case of big dump file, directory /tmp can be saturated with the
testCorruptedFiles test.

Fixes #377
Useful when reading a SRTM tile which needs the also reading of the
geoid that use SimpleTile.getElevationAtIndices method, which is dumped,
and lead to wrongly dump geoid data.

If the flag is set to true, we use in the DumpReplayer the default
MultiLayerModel. In case the user uses another model, one must asks the
user's model for debug purpose.
The dump files were updated to add the atmospheric refraction flag in
the direct loc and inverse loc lines.

Fixes #377

Complete Issue 376 resolution, as the solution was not converging in
some cases.

Conflicts:
	src/test/java/org/orekit/rugged/errors/DumpReplayerTest.java

refiningIntersection

Fixes #376

refiningIntersection

Fixes #376