ENH: Events Class and Flight Rework

[MateusStano]

Summary

The addition of custom events was long overdue. In this PR the Event class was added. It was basically impossible to do this without changing a lot of the flight class, so I took the opportunity to rework it and solve all TODOs there.

Several upcoming features will build on top of this (parafoil, multistage, more controllers...), so I want this branch to act as a hub for a few related changes:

• Make class Event serializable
  • Fix broken tests (broken due to fails on controller serialization)
• Rework controllers (minor) so they are better designed for use with specific classes, like what is done in FEAT: new actuator class for roll, throttle, and thrust vector control #965.
• Make flight.solution an instance of a new Solution class. It should behave like the current array, but also allow a variable state length. This is important for adding new parachute models such as parafoil, and for letting us define more complex derivative functions.
• Aerodynamic classes refactor to make GenericSurface the mother class of all other aero surfaces.

Here is a summary of all the changes:

flight.py

Some flight class methods were reworked, some were moved:

• The flight now moves forward using events, not a fixed list of phases.
• flight_derivatives.py: the motion functions (u_dot, u_dot_generalized,
  u_dot_generalized_3dof, rail and parachute), moved out of flight.py.
• flight_phase.py: now has the _FlightPhases and _TimeNodes classes.
• event_calling.py: utilities for callling the events in the flight class correctly
• event_commands.py: applies the commands an event returns back to the flight.
• a propper logging feature was added

New event code (rocketpy/simulation/events/)

• event.py (Event): An event has a trigger and a callback. The trigger is checked each step; when it is true, the callback runs. Callbacks can read the state, save data, log results, and send commands that change the simulation. It comes with ready-made presets like apogee and burnout. It also only computes expensive values when an event actually needs them.
• commands.py (Commands): what a callback can ask for. An event can start a
  new phase, swap the motion function, turn other events on or off, add or
  remove controllers, undo a step (rollback), or stop the flight.
• event_builders.py: ready-made events that recreate the normal flight steps
  (like leaving the rail).
• exact_time_solvers.py: finds the exact time an event happens inside a step
  (using a few math methods).

Parachutes, controllers and sensors are no longer special cases in the flight loop. Each one now has a to_event() method that wraps it into an Event. The built-in flight milestones (apogee, out of rail, impact) are now events too.

Parachute triggers and Controllers controller_function now take **kwargs only and read what they need by name (pressure, height_agl, state, sensors, etc.); the old positional parachute and controller signatures still work but raise a DeprecationWarning.

Flight.__init_events() just collects all events (core events, then sensors, parachutes, controllers, and user custom events) and runs them uniformly, and commands an event returns (like swapping the derivative or starting a phase) are applied back to the flight by event_commands.py.

Parachute noise was also removed. The noise parameter on Parachute is now deprecated and has no effect (removal in v1.13). To model a noisy trigger, a Barometer should be used and accesses the noisy measurement in the trigger via kwargs['sensors_by_name']. This fits the new model, where sensors are events and the trigger reads their measurements.

Plots and prints

• flight_plots.py and flight_prints.py now show sensor data too.
• compare_flights.py updated.
• New plots to all_info, and now they show case events:

Docs

• New guides: docs/user/event_usage.rst and docs/user/sensors_usage.rst.
• New technical page: docs/technical/simulation_loop.rst.
• Update all places that used old definition of trigger functions (with positional arguments) to now be used with **kwargs

Notes for reviewers

This will be a difficult one to review, specially because the diff tracking in flight.py is not that helpful given I changed the order of a few methods. So I suggest that the best way to understand how events work is to read the user guide: docs/user/event_usage.rst. It walks through the API with runnable examples.

Breaking change

• No (I hope)