sensors: prevent double orb_copy of gyro topic
sensors: prevent double orb_copy of gyro topic

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

krbeverx/Firmware,PX4/Firmware,dagar/Firmware,mje-nz/PX4-Firmware,dagar/Firmware,PX4/Firmware,mje-nz/PX4-Firmware,PX4/Firmware,acfloria/Firmware,acfloria/Firmware,dagar/Firmware,krbeverx/Firmware,mje-nz/PX4-Firmware,PX4/Firmware,krbeverx/Firmware,acfloria/Firmware,krbeverx/Firmware,dagar/Firmware,mje-nz/PX4-Firmware,mje-nz/PX4-Firmware,acfloria/Firmware,krbeverx/Firmware,krbeverx/Firmware,PX4/Firmware,mje-nz/PX4-Firmware,krbeverx/Firmware,mje-nz/PX4-Firmware,dagar/Firmware,acfloria/Firmware,acfloria/Firmware,dagar/Firmware,PX4/Firmware,PX4/Firmware,acfloria/Firmware,dagar/Firmware