amsl_origin and utm_origin now correctly use altitude from RTK instead of GNSS

[petrlmat]

Merge only when we verify that this works in real world. So far we have tested it in sim only.

• This concerns only EMLID RTK receivers. Holybro F9P is not affected as it is connected into pixhawk and not into NUC.
• So far, the amsl transformations (amsl_origin, utm_origin) published by transform_manager were based on the topic hw_api/altitude, which was based on the GNSS altitude reported by mavros/pixhawk.
• Now, when RTK is available (it is in the list of state estimators in custom config), the RTK altitude will be used instead.
• The altitude is using the tf fcu -> rtk_antenna to transform the measurements received by the antenna into the fcu frame, which is typically offset vertically on the drones.
• The fcu -> rtk_antenna tf was previously published from sensors.launch but I deleted the tf from the launch file because it is drone-specific and thus is the responsibility of the user to provide them in the tmux session. If the tf is not provided, transform manager will crash and inform the user to provide the tf.
• Affected tfs: fcu -> amsl_origin - contains only the amsl altitude (no xy position or orientation), fcu -> utm_origin - contains the amsl altitude, the xy position in the utm frame (latlon converted to meters), and the orientation.
• EMLID uses the WGS84 ellipsoid model for altitude and we don't do any conversion, so our altitude is also in WGS84. Pixhawk uses geographiclib to convert GNSS WGS84 data into some geoid model (one of EGM2008, EGM96, EGM84), so the altitude in hw_api/gnss (pixhawk) and hw_api/rtk (emlid) will differ by tens of meters (depending on the location).