When only latitude and longitude are specified, the elevation is
automatically computed from the Digital Elevation Model.

The new name explains more clearly that several sensors can be set up at
once.

We now use a single position for all pixels (but of course still
different line-of-sight vectors), as it doesn't really make sense to
consider different positions as pixels are only a few microns away from
each other.

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.

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.