Problem description at: http://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685

- Accel: use cutoff of 62.5 Hz instead of 500 Hz
- Gyro: the cutoff frequency is coupled with the ODR and is fixed to 116 Hz
  at 1 kHz readout rate. So this patch does not change anything for the
  gyro.

Move variable initializations to header file that were no longer in the correct order in the constructor list.

Deprecate #defines that are not needed, format whitespace and minor (incomplete) alphebetization of a few lists.

There is only one occurence of the namespace specified,
so it's more readable to simply specify the full namespace in this case.

Because BATT_SMBUS is using a different structure (the ModuleBase class), and `BATT_SMBUS::task_spawn` is only called for the `start` command. This is the reason why you don't need to check for it in here.

Co-Authored-By: BazookaJoe1900 <BazookaJoe1900@gmail.com>

Co-Authored-By: BazookaJoe1900 <BazookaJoe1900@gmail.com>

Co-Authored-By: BazookaJoe1900 <BazookaJoe1900@gmail.com>

Co-Authored-By: BazookaJoe1900 <BazookaJoe1900@gmail.com>

Co-Authored-By: BazookaJoe1900 <BazookaJoe1900@gmail.com>

using only <px4_getopt.h> as include, cleanup related includes
added check that all the option are valid (myoptind >= argc). if there are invalid options on some script that might now lead not to run commands

the mode can be used for VIO algorithms and obstacle avoidance to close the loop

Add perf_free() calls orb_unsubscribe and remove delete _instance in the Simulator class destructor.

Move remaining variable initialization from constructor list and alphabetize/organize methods and vars ordering.

 - closes #10133

Rename tune_control_s strength to volume to match Nuttx and Linux standard nomenclature for audio (loudness) control.

e.g. 
Preflight Fail: Height estimate error
Preflight Fail: Velocity estimate error
Preflight Fail: Position estimate error
Preflight Fail: Yaw estimate error

My recent PR exceeded the 50 char limit (apparently the last character must be null?).

This new attempt changes: "Preflight Fail: Horizontal position estimate Error"  to: "Preflight Fail: Position estimate Error"

In fact, this newest wording is more easily understood by the average user and is actually more consistent with the other COM_ARM_EKF_xxx related errors:

COM_ARM_EKF_HGT --> "Preflight Fail: Height estimate Error"
COM_ARM_EKF_VEL --> "Preflight Fail: Velocity estimate Error"
COM_ARM_EKF_POS --> "Preflight Fail: Position estimate Error"

Includes https://github.com/PX4/sitl_gazebo/pull/283

This updates the jMAVSim submodule which includes a fix for HITL.
In order to fix HITL, a CLI argument `-lockstep` was required to enable
lockstep. This has now been added to the command in jmavsim_run.sh.

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".

 - need to update to python3 coverage.py.

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.