Can be used to immediately get & use the data, as needed for the flight
tasks.

FlightTasks: initialize task state based on subscriptions after the SubscriptionArray was initialized

I think this is more how it's meant to be

This is to avoid dynamic (re-)allocations on task switching, due to
orb_{un,}subscribe calls.

In addition, we will need some shared data structure for the uorb
subscriptions.

FlightTask: move setter back into header and switched argument to reference to have them inlined by the compiler

FlightTask: fix CI: static field requiring definition in cpp file, errors with clang linker (CI) but not with GCC

FlightTasks: private variables follow underscore name convention, member description comments doxygen style

FlightTask: move position and stick data subscription into tasks, Orbit introduce variable center position

FlightTasks: revised task switching algorithm to catch errors during activation of a new task and make it more readable

FlightTaskManual: Smooth flight integration: refactored and checked second half of get_acceleration_xy executing the intention

FlightTaskManual: Smooth flight integration: refactored and checked first half of get_acceleration_xy determining the xy user intention

FlightTaskManual: Smooth flight integration: slewrate now works, set to 0.2m/s^2 in all dimensions for testing

    analyzing detailed semantic and external uses of the variables still necessary

FlightTaskManual: Smooth flight integration: Make set_manual_acceleration_z without any refactoring compile
analyzing detailed semantic and external uses of the variables still necessary

FlightTaskManual: Smooth flight integration: Copy over set_manual_acceleration_z without any changes

FlightTaskManual: Smooth flight integration: Make set_manual_acceleration_xy without any refactoring compile
analyzing detailed semantic and external uses of the variables still necessary

FlightTaskManual: Smooth flight integration: Copy over set_manual_acceleration_xy without any changes

removed and added comments