By using the uORB::Subscription API we use a separate subscription
rather than `orb_copy` on the existing file descriptor used in
sensors through `px4_poll`.

This fixes a very peculiar problem that we observed in SITL in CI for
fixedwing. The events were as follows:

1. `sensors` does `px4_poll` on the gyro topic (as normal), and gets
   the latest sample using `orb_copy`.
2. A parameter update happens when the mag is initialized and triggers
   `VotedSensorsUpdate::parameters_update()` where `orb_copy` happens
   before the main loop in `sensors` has started a `px4_poll`.
3. `sensors` now does the `px4_poll`, however waits indefinitely because
   it has already copied the latest sample.
   Also, the `px4_poll` will never time out because in lockstep the
   simulator waits for the next actuator control message which it never
   gets and therefore it never sends the next sensor message with a new
   timestamp to advance the time.

This only happens for fixedwing because there is only one "uORB path"
through the system unlike for multicopter where a gyro sample can get
picked up by either `sensors` or directly `mc_att_control`, so the
system can survive if `sensors` has "drops".

Rate changes were doing an asynchronous register reload via the EGR_UG. This could extend a PWM pulse up to 2X.

This fix removes the asynchronous update. The net effect is the the rate change will occur on the next counter expiration. The worst case is the rate change is delayed by 20 Ms.

changed: "Mission rejected: land start required."
to: "Mission rejected: landing pattern required."

This new message is more clear to the average user.  When using RTL_TYPE = 1, mission feasibility checker adds the requirement of a landing sequence beginning with a MAV_CMD_DO_LAND_START and ending with a MAV_CMD_NAV_LAND with at least 1 other waypoint prior to the land waypoint.  The warning message "Mission rejected: land start required." is a common warning to trigger whenever the mission is blank or the mission is uploaded without a landing pattern.  The wording in this message confusing to the average user as they usually do not know the inner workings of the "landing pattern" that their planning software helps them make (e.g. Qgroundcontrol).  The only users who would know what a "Do_Land_Start" mission item is are advanced users already and this new message should work equally well for them as well as the non-advanced user.

changed: "Preflight Fail: Horizontal estimate Pos Error"
to: "Preflight Fail: Horizontal position estimate Error"

The comment description for COM_POS_FS_EPH incorrectly stated "...horizontal position error (EPV)...".  This fixes the acronym to "(EPH)".

mc_pos_control - reduce smooth_velocity_takeoff default threshold, set initial takeoff speed to 0 and remove useless else

PositionControl - use dynamic constraints to saturate velocity controller for now as it is needed for the current smooth takeoff logic. Will be reverted after smooth takeoff refactor

Position Controller - Saturate the controllers using static parameters. Handle saturations in the flight tasks only

Manual vel smooth - use speed_up and speed_down constraints to limit velocity target of the trajectory generator

 - also applies to mission_stats_entry_s, mission_fence_point_s,
   mission_save_point_s
 - -Wpadded warning is disabled by default because the snapdragon
   toolchain doesn't respect the pragma pop

Fixes regression from https://github.com/PX4/Firmware/pull/11216.

 - Remove a constructor overload by adding default values, and disambiguate a few variables by adding verbosity to naming.