Reason: the value is easier to read & handle (for example plotting). In
most places the value is needed, not the integral.

Note that this breaks the replay format for sdlog2 replay

This is needed for the new logger & saves some space as well.

There is no reason to make this 64 bit. The same should be done in
the sensor raw messages, together with further cleanup.

- voting is now at a central place instead of duplicated within the
  estimators
  -> this also means that estimators that did not do voting so far,
     now have voting, like ekf2
- estimators requiring more than that can still subscribe to the raw
  sensors
- allows sensors_combined to be 3 times smaller
  - reduces logger, memcpy (cache) & RAM overhead
- all modules requiring only 1 or 2 sensor values now automatically get
  the voted result
- this also adds voting to baro

Decreases the message size from 780 to 280 bytes.
In particular, all modules using sensor_combined must use the integral now.
The sensor value can easily be reconstructed by dividing with dt.

Voters now need to be moved into sensors module, because error count and
priority is removed from the topic.

Any module that requires additional data from a sensor can subscribe to
the raw sensor topics.

At two places, values are set to zero instead of subscribing to the raw
sensors (with the assumption that no one reads them):
- mavlink mavlink_highres_imu_t::abs_pressure
- sdlog2: sensor temperatures

These are not really used. differential_pressure is just copied from the
topic with the same name.

for sdlog2 we assume no one needs the diff pressure fields and set it to 0.
We plan to switch to the new logger soon anyway.

Drawbacks of the previous method: when writing to the SD card, there are
high delays in the write() call of several 100ms, every now and then. The
frequency and length of these events depend on:
- SD card
- used logger bandwidth
- bandwidth of gps data (RTCM)
Since the whole gps thread was blocked during this period, it lead to
gps timeouts and lost module.

What we do now is: publish an orb topic with queuing. This makes it async
and the logger takes care of buffering. This means it's best to:
- use high logger rate
- use large logger buffer
- reduce logger bandwith by disabling unused topics

We need to make this timestamp relative to the main timestamp. Necessary
for replay, and saves some space.

timestamp was unused. This allows to remove timestamp_position.

Signed-off-by: Roman <bapstr@ethz.ch>

remove unnecessary replay fields

Instead we use o_name to get the topic name. Now the topic names are not
upper case anymore in the log format. This makes it more consistent, eg.
if used as a nested topic

We explicitly include the timestamp. This makes it possible to change it's
type later on.
This breaks the current ULog logging format.

This makes sure that adding & removing of .msg files is handled properly
by the build system.

This also greatly speeds up the generators.

This is required for the logger, we just manually add the padding bytes
what would otherwise be done by the compiler. Additionally we reorder
the fields by type, so that padding is only necessary for nested types.