Fix the issue with rise / set / transit times of Jupiter's Moons

Jupiters Moons are TrailObjects, and so riseSetTimeUT() calls
SkyPoint::updateCoords() -- the "vanilla" update of coordinates that
doesn't account for the motion of the planets.

Thus, one would have expected at least approximate rise/set times for
Jupiter moons to be displayed -- treating them as if they were objects
with fixed catalog RA0 / Dec0. However, we were displaying something
way off.

This is because we were setting current (RA, Dec) of the moons from
JupiterMoons::findPosition(), but we were not setting the "catalog"
(RA0, Dec0). Thereafter, SkyPoint::updateCoords() would happily call
precess() when it detected a sufficient change in JD, overwriting the
calculated (RA, Dec) with some junk that comes from precessing a junk
values of (RA0, Dec0) to the current epoch.

This patch calls SkyPoint::deprecess() to convert that (RA, Dec)
calculated in JupiterMoons::findPosition() to (RA0, Dec0) and resets
it appropriately, so that when SkyPoint::updateCoords() is called, it
writes out the (RA, Dec) computed back from this (RA0, Dec0), and not
some junk.

However, this is not perfectly accurate. For one, it seems like we
don't de-nutate. Besides, it looks like we never aberrate (is
aberration even relevant to planets?). So assuming that the nutation
and aberration are small enough, this yields a solution that's not
terribly off from what it should actually be.

Besides, we should actually be updating Jupiters' moons' rise / set
times as though they were planets, not as though they were generic
sky-points with fixed (RA0, Dec0). They would certainly move quite a
bit in the order of hours, so we should ideally implement a PlanetMoon
and JupiterMoon class and have a PlanetMoon::updateCoords(), even if
all it does is call JupiterMoons::findPosition().

CCMAIL: kstars-devel@kde.org

BUG: 340946