With the previous value of 20ms, we dropped RC input when not armed. The
result was that some RC channels jumped randomly between min & max.

This closes the fd and cleans up a static variable used in the dsm parser.

This was only a problem when running as a task not on the work queue.
The problem was that init() opened the RC serial device, which was then
read in the main loop, which is a different context when run as a task.

  Both PX4Test and Beat noted if only Brick to was connected
  battery_status Intance 0 voltage was 0V for Brick2

  The priority selection logic is run prior to the subscription
  creation and only updated the priority on a change. Before the
  subscriotions were created.

  _battery_pub_intance0ndx is suposed track the location in
  the _battery_pub array that is instance 0. It is then used
  to associate (move) instance 0 with (to)  the lowest brick
  (highest priority in HW) brick that is selected in HW.

  The Bug was that before the subscriptions are created,
  _battery_pub_intance0ndx set to 1. And then and never updated.

  The fix was to only run the priority selection logic once
  the subscriptions are created.

   BOARD_HAS_LTC44XX_VALIDS - 0 -> No LTC44xx IC, N is the number of
                              Power Bricks connected to the LTC44xx
                              For a LTC4417 this would be 2 as the
                              third prioriy is used for USB

   BOARD_HAS_USB_VALID     - If defied as 1 imples that infact
                             the USB has a priority connection
                             on the LTC44XX

   BOARD_HAS_NBAT_V       - the number of battery voltage sensing chennels
                            on the ADC

   BOARD_HAS_NBAT_I      - the number of battery current  sensing chennels
                            on the ADC

   A super simple (non FMUv5 compliant) board with no LTC44xx and just one battery
   that have no current sense:

    BOARD_HAS_LTC44XX_VALIDS = 0
    BOARD_HAS_USB_VALID      = 0
    BOARD_HAS_NBAT_V         = 1
    BOARD_HAS_NBAT_0         = 0

   A fully FMUv5 compliant design would use:

    BOARD_HAS_LTC44XX_VALIDS = 2
    BOARD_HAS_USB_VALID      = 1
    BOARD_HAS_NBAT_V         = 2
    BOARD_HAS_NBAT_0         = 2

   These setting properly condition the ADC channles and all the Power
   module valid sensing logic in the ADC module.

   Removed unused headers and placed the __BEGIN_DECLS where it belonged

   voltage3V3_v - the sensor 3.3V voltage rail
   v3v3_valid   - the value of voltage3V3_v  may be 0. This
                  field is a 1 when the HW provides voltage3V3_v

   brick_valid - is now a bit mask. A 1 in the postion inticate the
                 Power controler HW has a valid supply voltage
                 present (in V window) on that priority
                 (channel V1..Vn).
                 The mapping is formed by 1<<battery_status.msg.priority
                 or using the manifest constanst BRICKn_VALID_MASK

   usb_vaild - is now indicated from the Power controler HW or
               the usb_connected if Power controler is
               not present.

   brick_valid == 0 and usb_vaild = 1 implies the FMU is powered
   from USB only

   brick_valid != 0  and usb_vaild = 1 implies the FMU is powered
   from the higest priority brick, providing a 1 bit in brick_valid
   and from USB

   This change implements the publishing of batery_status messages
   for each brick on the system, using multi-pub.

   Backward compatiblity is achived by always publishing the
   batery_status of the bick that has been selected by the HW
   Power Controller (PC) on instance 0.

   The batery_status.system_source will be true in one and
   only one batery_status publication when a valid bit is
   set in system_power.brick_valid. However, if USB is connected,
   and both brikcs are not providing voltages to the PC
   that are in the Under/Over Voltage Window (set in HW)
   the system_source may be false in all publications.

   FMUv4Pro and FMUv5 Spec added multi brick support
   FMUv5 added SCALED_VDD_3V3_SENSORS

   This change provides legacy (FMUv2) defaults for Power Bricks and
   Sensor rail volatage source.

   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

   The PX4IO is an population option on some varients. To have
   1) FMU only control
   2) IO Only control
   3) FMU fall back control

   These pins need to come up as inputs, until the configuration
   is determined.

   Dispite what the ref manaul says. Some HW needs the added pull
   down to insure the pin reads low when not plugged in to USB.

  Added comments to ADC defines with Pin numbers.
  Added the GPIO_HW_{REV:VER}_DRIVE signals
  Define the GPIO_nPOWER_IN_{A:C] and assign them to
  BRICK1, BRICK2 and USB Valid.
  Regroupped power signals and defined true logic Power Control macros
  in the arch agnostic form.
  Defined the same IOCTL defines for FMU GPIO IOCTL
  Use the power Control macros on board_app_initialize

  As done on fmuV4 on resets invoked from system (not boot) insure
  we establish a low output state (discharge the pins) on PWM pins
  before they become inputs as a result of the pending reset.

  We also delay the reset by 400 MS to insure the 3.1 Ms pulse is
  not too close to the last PWM pulse.

  The LTC4417 provides a valid signals for brick1, brick 2 and USB
  This change  configures the GIOP and provides 1) a MACRO to read
  the pin and 2) the IOCTL defines to read it from the FMU.

  The macro's result is true logic: It is true when the signal is active.
  (Active low on the the LTC4417). The IOCTL read would be the actual
  pin state.

  The V4 HW replaced the LTC4417 provided valid signal for USB.
  with an active high, version. This commit configures the GIOP
  and provides 1) a MACRO to read the pin and the IOCTL defines
  to read it from the FMU. The macro result true logic: true
  when the signal is high. The IOCTL read would be the actual
  pin state.

   The LTC4417 provides a valid signal for USB. This change
   configures the GIOP and provides 1) True logic macro to
   read the pin and the IOCTL defines to read it from the FMU.
   The macro will return true when the signal is active (low
   on the LTC4417). The IOCTL will read be the actual pin state.

   Since Hardware flow control has not been enabled this typo
   survived.

   board_spi_reset is used to reset the internal SPI bus.
   therefore GPIO_SPI5_DRDY7_EXTERNAL1 should not have been
   minipulated, as it is on SPI5

   GPIO_nVDD_5V_PERIPH_EN is Active low. board_peripheral_reset
   need to tune it OFF then ON