Feature/bsk 857 polymorphic state data

[juan-g-bonilla]

• Tickets addressed: closes Make StateData polymorphic to support alternative state propagation equations #857
• Review: By commit
• Merge strategy: Merge (no squash)

Description

StateData was made polymorphic, StateData::propagateState is now virtual.

This also required improvements to how the integrators work. ExtendedStateVector was given additional methods and updated to handle the polymorphic StateData. Similarly, DynParamManager had to be updated (registerState is now a templated method for different state classes, for example). Unfortunately, this means a SWIG file is now necessary for DynParamManager (templated code needs some extra massaging in SWIG), which in turn means a lot of SWIG interface files must be updated to use this new SWIG file.

I'm a good boy scout, so I also tried to clean up code and add extra docstrings in these classes.

Verification

Commit 8976004 (or it's current equivalent) removes support for operator+ and operator* on StateData, that test_stateArchitecture depended on. This test has been updated to use other, equivalent, methods.

No new tests added. Essentially all other Basilisk tests use StateData and integration, thus these tests passing should prove the refactored system works as expected. For now, only one StateData class appears in Basilisk (with the standard propagation function), and that should be shown to work. New StateData classes should be tested as they are implemented.

Documentation

No changes. API remains very similar: by default DynParamManager assumes you want to create a standard StateData. The state system is not discussed on the prosaic documentation, thus no changes are needed.

Future work

Implement custom StateData classes, such as the MRPStateData or QuaternionStateData classes described in #857

[juan-g-bonilla]

Ola @joaogvcarneiro! I have a test failing for this branch. It's related to the variable integrator scenario, which I believe you wrote?

I made some changes to the adaptive integrators. The math should be the same, but the numerics have shifted around. I think the failing test is testing to an accuracy that is within the integrator error, so the updated numerics trigger the comparison failure. That's only my intuition, so I'd appreciate your take on it if you have a minute.