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.
Claiming that we agreed to make Orbitable while keeping all user-visible API calls exactly as they are now without changing them one bit is inherently contradictory.  Its like claiming we agreed to make a triangle with four sides, which is why I'm getting very frustrated here.

Correcting the fact that the Body and Vessel APIs differ from each other in ways that they shouldn't is a *prerequisite* of moving that behavior into the base Orbitable class.  That *is* a change to the user-visible API because it means giving Body a lot of suffixes it didn't have before that had previously been Vessel-only suffixes.  If you don't give Body additional suffixes (an API change), and you don't make Body's VELOCITY into the same type of thing as Vessel's VELOCITY (also an API change), then the Orbitable parent class becomes mostly empty and has no point.

You're acting as if this this is an argument over *whether* to change the API when it's not.  It's an argument over how MUCH to change it.  Getting Body and Velocity to agree with each other *already* requires a lot of user-visible API changes or else it's not even doable.

Changing the API *IS* in scope.  Now let's discuss how *much* is in scope for this PR and how much should be in a future PR, rather than trying to frame the argument like it's all or nothing, which isn't fair.