Refactor set_publish() logic so that a default false value is not (re)set each loop in simulator_mapvlink.cpp and provide a default argument to set_publish() in simulator.h.

Create Simulator::set_publish() method and Simulator::_publish member variable to allow redefinition of the Simulator::handle_message() prototype to match MavlinkReceiver::handle_message().

 - fixes #11317

The simulator had hardcoded component ID and system ID (sysID was 0), ignoring what was set up in the params MAV_SYS_ID and MAV_COMP_ID. This caused an issue with multi-vehicle simulations that that rely on sysID to identify the vehicles.

Signed-off-by: Gabriel Moreno <gabrielm@cs.cmu.edu>

In CONTRIBUTING.md, the current link to the coding style leads to a
404 error. I've replaced it with a link to the Source Code Management
part of the developer documentation, which is where the style guide
seems to be now.

This reverts commit 0df34af1.

   The cause of the stack detection fault is because of the
   level of nesting in the start up script. We need to
   determine the worst case configuration and set the
   bar there.

   This fault occurred some 42 calls deep due to script
   calling script (repeat).

   The HW stack check requires as a margin of 204 bytes. That is
   ISR HW stacking of CPU(8) FPU(18) registers and SW stacking of
   CPU(11) and FPU(16) registers. Total CPU(19) registers is
   68 bytes and the total FPU(34) registers is 136 bytes.  On
   a system with a separate ISR stack This only needs to be 104
   so there is 100 bytes of headroom. But as coded the detection
   will give a false positive detection and fault. This does not
   mean that the stack will be corrupted.

   Adjustments to that stack can have no effect due to rounding.
   A stack size of 2608 and 2616 can yield the exact same size stack.
   So even when the failure is due to a 4 byte overflow, it can take
   greater than a 16 bytes increase to fix it. Because the final
   stack size is calculated with an 8 byte alignment after a 4 byte
   decrease. So 2624 becomes 2620 at runtime and will boot
   with SYS_AUTOSTART=4001.

 - support range based for loops
 - add remove() method to remove a node
 - add clear() to empty entire list and delete nodes
 - add empty() helper

A side-effect of the previous commit is that the integral is loaded up
during a flip, which leads to visible bounce-backs after a flip.
Reducing the I helps, but there's a trade-off and we'll need a better
solution.

Except for the lower end with disabled airmode.

Otherwise the rate controller would disable the integrals, which can lead
to severe tracking loss in acro.
It is noticeable when flying in FPV, e.g. simply when throttling straight
up.

Relevant part in the rate controller:
https://github.com/PX4/Firmware/blob/master/src/modules/mc_att_control/mc_att_control_main.cpp#L702

Cut case MAVLINK_MSG_ID_HIL_STATE_QUATERNION content and paste into handle_message_hil_state_quaternion() method.

Cut case MAVLINK_MSG_ID_HIL_OPTICAL_FLOW content and paste into handle_message_hil_optical_flow() method.

Cut case MAVLINK_MSG_ID_DISTANCE_SENSOR content and paste into handle_message_distance_sensor() method.

Cut case MAVLINK_MSG_ID_LANDING_TARGET content and paste into handle_message_landing_target() method.

mission_feasibility_checker: takeoff: add a different log message when there's a takeoff item but it's not the first waypoint

mission_feasibility_checker: takeoff: accept mission when takeoff is not the first item but the previous items are not waypoints

navigator: mission feasibility checker: check for a takeoff waypoint on mission on specific conditions

 - the Jenkins slave now has the gdb server already started in the background