The former implementation ignored the flat-body flag and in fact
corrected the flat-body ...

The current altitude must be considered when computing light time
correction. Previous computation was slightly wrong as it only computed
light time from the ellipsoid. This induced problems when computing
inverse correction.

In some cases, the line of sight has two intersections with a given
iso-latitude cone, and the selecting the closes one to spacecraft was
not always the appropriate choice. An hint from the caller was needed,
as a point close to the desired intersection.

It works in simple cases (no light time correction and no aberration of
light correction), and is still really slow.

The indices are now checked at caller level.

This option is mainly intended for comparison with existing systems. It
should not be used for operational systems and the full Duvenhage
algorithm with line-of-sight bending in geodetic coordinates should be
used instead.

This will allow implementing inverse localization.

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.