On the Intel Aero and probably also other specific platforms
the first measured voltage values despite connected battery are unuasable.
The solution here is to start filtering and determining warning
only after a measurement above 2.1V was received.

Battery: enhanced voltage, capacity estimate fusion, set empty voltage to a useful value for reasonable lipo usage

Battery: refactor _param out of the variable names and use 0.f for zero floats to make code more readable

   Connected is assumed when the battery voltages is greater than
   a predefined level.

   system_source - This battery status is for the brick that is
                   supplying VDD_5V_IN
   priority      - Zero based, This battery status is for the brick
                   that is connected to the Power controller's
                   N-1 priority input. V1..VN. 0 would normally be
                   Brick1, 1 for Brick2 etc

  Battery now assigns connected from the api in the
  updateBatteryStatus, as well as system_source and priority

We need to differentiate between a level where the user should act and where we are about to fall out of the sky (emergency). This helps performing more suitable failsafe actions.

Battery charge estimation: Refactor the filtering strategy and move it to the backend, doing integration before and filtering the resulting charge estimate

The commander used to consume the battery_status topic and write the
contents after some calculations into the system state. Instead, the
calculations now happen in library calls in systemlib/battery.

This moves the battery fields out of the vehicle_status message into the
battery_status topic.

This brought quite some changes in all modules that need battery
information. The current state is compiling but untested.