This requires further investigation. Hotfix.

   This commit fixed a bug were the mag was orphened on a reset.
   That resulted in MAG timeouts on reset or test operations and
   left the mag in a broken state.

   If the setup is unsucessful fo not register the devices or
   allocate resources.

  We want to setup the mag interface with retries and report
  failurs.

  Move retry logic to contol point, instead of hiding re-reading
  the ID in ak8963_check_id.

  Allow it to fail once to overcome a read of 0 on firt read.
  after 2 failure report error to console and reset the
  mpu9250's I2C master (SPI to I2C bridge)

  The same retry logic is used on the ak8963_read_adjustments
  with a reset of the I2C master module after 5 fails. If it
  fails fter 10 retires. Disabel the mad and report the failure
  on the console, stating it is disabled.

   Provide an API for the mag to use read-modify-write

   On initialization, if after 3 retries to re-init the mpu9250 from
   the checked registers values, it fails. Ensure thath the fact the
   driver is exitting is logged to console.

   Check that the mpu9250's configured registers match the settings
   written to them. Attempt to fix any that do not up to 3 times.
   printing erros to the console on mismatches and returning
   faliure if after 3 attempts the any of the values are
   still wrong.

   Remove delays on each register write in the
   reset function. Leaving only the delay
   following chip reset prior to configurations.

- change/add a few printfs so they make more sense
- don't accidentally ignore command_acks
- don't forward commands to the same component id, and don't forward
  commands that are broadcast to all components (target component 0)

This adds a class to allow for retransmission of outgoing commands.
The sent commands are kept in a timestamped list to check if they are
acked as required by the mavlink protocol.
If they are not acked within a timeout, they can be retransmitted.

The vehicle_command uORB messages had the timestamp unset at 0.

It makes sense to have this for all standard planes and our default PWM outputs for MAIN are always 6 wide, so this should scale to all known HW platforms.

Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.

The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms. 

This change delays the reset and therefore the pulse by at least 400 Ms.

  On resets invoked from system (not boot) insure we establish a low
  output state (discharge the pins) on PWM pins before they become
  inputs.

Note that Type buf_adc[i].am_data = int32_t, but everything else are floats. Suggest (float)(buf_adc[i].am_data), precisely as was done a few lines later for the voltage.

- one warn_rate_limited was missing
- vel_sp_slewrate was in the wrong order for smooth slowdown/speedup on takeoff and landing
- slow_land_gradual_velocity_limit was replaced by calls to math::gradual
- smooth takeoff speed got controllable by user input
- comments were corrected
- an additional check for the sanity of velocity setpoints was added