including tfinal when integrating an orbit

[M1ssing-N0]

Currently, the time of the last sample is (tfinal-tstep) instead of tfinal.
I edited the code to extend the integration until tfinal which may be more intuitive.
I also include more sanity check (e.g., tfinal>tinit) for better quality of life.

[michael-petersen]

Thanks for getting started on this!

I understand that the goal here is a use case where you have finer control to manually change the basis at some larger time step (i.e. sequence several IntegrateOrbits calls together), and right now the effective dt=(tfinal-tinitial)/h results in the orbits not being integrated to have an output at tfinal. Is that right?

Looking through, this will create some breaking changes, so I think we'll definitely want to think about whether this is the best way to implement the goal. We also probably want to have some defaults rather than nullopt, although the catches now will help with that.

[The9Cat]

This is an interesting approach, but we are very reluctant to change the IntegrateOrbits API. As Mike said, it will break existing scripts and applications. It would be better, at this point, to fix the internal step counts to ensure that the last point is tfinal. This was the intent of the code as written. Specifically, the goal of lines 3856-3865 is choose a step size that starts at tinit and ends exactly at tfinal (up to machine precision at least). If that is broken, let's fix that first.

[M1ssing-N0]

Thanks for your comments! I agree that I am making some aggressive changes like introducing nullopt.
The changes I made serve to:

1. Fix the missing output at tfinal (e.g., for tinit=0, tfinal=1, tstep=0.1, it will only integrate from 0 to 0.9), as mentioned by Michael,
2. Provide more consistency and sanity check for better quality of life,
3. Enable simultaneous input of h and nout, which is the reason for introducing optional arguments.
   Maybe I can focus on the first to objectives first? I can revert back the changes to arguments h and nout