Clarification and adjustments to how orbital coordinates are handled

[astronomerritt]

PPJoinEphemeridesAndOrbits checks to see if q is in the orbits file. If it isn't, it checks to see if a and e are present, and then calculates q assuming an elliptical orbit.

There are some problems here:

• Why is this check done here and not in PPReadOrbitFile?
• The error message if a and e aren't present is confusing and seems to inform the user that they can't use cometary elements at all and they must supply a.
• If a and e are supplied, but not q, q is calculated assuming an elliptical orbit. So if someone decided to run ISOs and for some reason defined the orbits with Keplerian elements instead of cometary, the code would then quietly miscalculate q.

I don't know how likely it is that the latter would happen -- using cometary format for ISOs makes more sense to me intuitively, but I'm not an expert. Either way, I think checks and calculations of orbital elements need to be done in PPReadOrbitFile and I think the error message should make more sense.

[astronomerritt]

As a note, I'm likely not touching this issue for now as we're currently working with the LINCC incubator so this may all get destroyed later anyway - this issue is just keeping a record of it so I know it's there.

[mschwamb]

If a and e are supplied, but not q, q is calculated assuming an elliptical orbit. So if someone decided to run ISOs and for some reason defined the orbits with Keplerian elements instead of cometary, the code would then quietly miscalculate q.

Note - a is invalid if q > 1. so you can't have an a if you're working with ISOs. It's undefined, so there should never be orbits with a and e> 1. The switch would be already made to cometary elements.

[mschwamb]

Closing because #497 will handle this.