This better matches physics naming conventions.

This setting is not intended to be used often (in fact it should be used
only for validation against other systems), so forcing user to set it in
all cases was a bad idea. Now the default configuration is to compensate
and if user does not want to compensate, he can inhibate it by calling a
separate method after construction.

We now use directly Orekit PVCoordinates and Apache Commons Math
Rotation classes.

We use directly the Orekit GeodeticPoint now.

As the time between each line is really small (milliseconds), it is
better to propagate first and use an ephemeris later.

The low point at tile minimum elevation was computed with a tiny
positive error, meaning the point really was above min elevation (at
micrometer level). The line segment between entry and exit stopped just
before traversing the Digital Elevation Model, and an error was
triggered.

The solution was to take some margin when computing the segment
endpoints at entry and exit: we now start above max elevation and end
below min elevation so the intersection should be really on the line. 

There were some small errors (at centimeter level) as result points may
be slightly out of line of sight. These errors seemed to be due to the
final linear line-of-sight model that is used at pixel level.

An iterative correction step is performed to ensure the point is really
on the line-of-sight.

The residual error is now at nanometer level.

The conversion is of course accurate only in the neighborhood of the
reference point, as a straight line in Cartesian is not a straight line
in geodetic coordinates. What is converted is the initial direction so
the two curves are tangent at the reference point.

Near Earth surface, the two curves remain within one millimeter of each
other after about 100 m travel.