Orbitable base class Resolves #133

Please see issue #133 for a long, full list of the user-visible changes.

The reason so many files are affected is that the constructors had to
be changed slightly so everywhere a VesselTarget or BodyTarget are created
was modified a little.  Also a few places were changed to operate on the new
generic Orbitable object so they now operate on Bodies as well as Vessels.
It does not add to the bloat because it moved the definitions that are common out of VesselTarget and BodyTarget into the parent class.  The list of suffixes defined for JUST VesselTarget alone and JUST BodyTarget alone are now shorter lists than they were before.

If you wanted everything obtainable from Orbit that is common between Vessel and Body be obtained ONLY from Orbit, moved out into the Orbit class instead, that would have been an entirely different design and renders the entire idea I proposed a week ago utterly moot.

Why?  Because:
Velocity is obtainable from orbit.
Altitude is obtainable from orbit.
Position is obtainable from orbit.
Once you have the above as vectors, then all the Direction versions are calculable as well (Prograde, Retrograde, srfprograde, srfretrorade, etc).

The design idea that takes advantage of this would be to make VesselTarget and BodyTarget congruent NOT by subclassing them from a common parent that implements their common operations, but instead by moving those common operations out into the Orbit class.

And thinking ahead to the future, that's a problem when it comes to writing the eventual routines that predict future positions, because the orbit patch does not know about the planned maneuver nodes - only the vessel its associated with does, and it's a bad idea to keep a handle on that vessel inside Orbit because of issue #107.

Basically, moving these fields out of Orbitable and into Orbit is NOT a small change to what I did.  It's rendering what I did utterly pointless by going with a different design from the ground up.