Fix continuity and states for start within maneuver

Description

This is a slightly subtle bug that showed up in https://github.com/acisops/acis_thermal_check/pull/30#issuecomment-665240053. When requesting states starting within a maneuver it could happen that datestart > datestop in the first state. The first datestart was incorrect, but otherwise the state values were good. For example:

# BEFORE
In [4]: sts = states.get_states('2017:207:23:35:00', '2017:208', state_keys=['pitch'])                                                                
In [5]: sts                                                                                                                                           
Out[5]: 
<Table length=6>
      datestart              datestop           tstart        tstop           pitch        trans_keys
        str21                 str21            float64       float64         float64         object  
--------------------- --------------------- ------------- ------------- ------------------ ----------
2017:207:23:35:00.000 2017:207:23:27:18.468 617499369.184 617498907.652 110.87282500007102           
2017:207:23:27:18.468 2017:207:23:32:20.933 617498907.652 617499210.117  88.55915279194639      pitch
2017:207:23:32:20.933 2017:207:23:37:23.398 617499210.117 617499512.582  69.54669822454251      pitch
2017:207:23:37:23.398 2017:207:23:42:25.863 617499512.582 617499815.047  59.41050320985601      pitch
2017:207:23:42:25.863 2017:207:23:45:30.816 617499815.047 617500000.000  57.13454809508824      pitch
2017:207:23:45:30.816 2017:208:00:00:00.000 617500000.000 617500869.184 57.132522367348834      pitch

# AFTER the fix
In [2]: sts = states.get_states('2017:207:23:35:00', '2017:208', state_keys=['pitch'])                                                                                     
In [3]: sts                                                                                                                                                                
Out[3]: 
<Table length=4>
      datestart              datestop           tstart        tstop           pitch        trans_keys
        str21                 str21            float64       float64         float64         object  
--------------------- --------------------- ------------- ------------- ------------------ ----------
2017:207:23:35:00.000 2017:207:23:37:23.398 617499369.184 617499512.582  69.54669822454251           
2017:207:23:37:23.398 2017:207:23:42:25.863 617499512.582 617499815.047  59.41050320985601      pitch
2017:207:23:42:25.863 2017:207:23:45:30.816 617499815.047 617500000.000  57.13454809508824      pitch
2017:207:23:45:30.816 2017:208:00:00:00.000 617500000.000 617500869.184 57.132522367348834      pitch

This is a consequence of the way maneuvers are handled, in particular that there is a command AOMANUVR that kicks off a maneuver and internally a number of pseudo-commands are injected in order to change the attitude and pitch, yaw, roll etc appropriately.

When calling get_states without a continuity specified, it first gets continuity for the start date. The bug here was that the continuity was providing continuity at the time of the AOMANUVR command, which would be OK except that the subsequent states processing was aware of the pseudo-commands that followed and created states accordingly. However, the states code assumes that the first state contains the continuity time. It explicitly sets the datestart of the first state to the input start time based on that assumption, but in this case a couple of new states due to the pseudo-commands were intervening and so the inconsistency appeared.

The fix is to ensure that the states which are generated in order to determine continuity go out to the desired continuity date instead of the time of the last actual (non-pseudo) command before that date. That gets everybody on the same page.

Testing

[x] Passes unit tests on MacOS, linux, Windows (at least one required)
[x] Functional testing

Functional testing

Confirmed that this fixes the original issue noted in https://github.com/acisops/acis_thermal_check/pull/30#issuecomment-665240053

sot / kadi