fix a spell error

To be more consistent with the rest of the system

For the process usage: we need to measure over a certain period of time,
then we can use the results. To avoid blocking, this does:
- after log is started, initialze the load counters, then one second later
  add the results to the log
- after disarming: continue logging for one more second, then add the process
  load to the log and stop logging.
- to avoid a delay, 'logger stop' will stop immediately and not log
  postflight process usage.

These can be used to print the perf counters to a buffer.

perf_counters is read from and written to by different threads and thus
requires synchronization. Without it we risk accessing invalid memory.

There are still remaining issues (see comment in code), they will not lead
to a crash however.

Instead of printing to an fd, this prints to a buffer and calls a callback
for each line. To avoid code duplication, the print_load has been refactored
to print to a buffer first, then print to an fd. The overhead is not
noticable, and the behavior of print_load is unchanged.

Because during the printf, the total_runtime could be changed by another
task. This is still not entirely race-free though.

assuming CONFIG_MAX_TASKS = 32, this saves 256B of RAM

what could have gone wrong before? A scheduling switch during the printload
could have led to a task exit, rendering the tcb invalid. After switching
back, printload would access invalid memory.

This keeps the sched_lock() section as small as possible, just grabbing the
tcb variables we need.

Also when formatting malvink mission items from internal mission items,
the INT flag should be obeyed.

The relative altitude flag was not set correclty when waypoints are sent
using the INT protocol.

       1) Revert the inherited dma bug from the stm32
       see https://bitbucket.org/nuttx/nuttx/commits/df9ae3c13fc2fff2c21ebdb098c520b11f43280d
       for details.

       2) Most all CR1-CR3 settings can not be configured while UE
          is true. Threfore we make all operation atomic and disable
          UE and restore it's originalstate on exit.

       N.B. This backport omits all upstream breaking changes.

   FMUv4 PRO HW does not have a controlable V3.3 on the connector
   it therefore can not support the SPEKTUM binding.
   This PR removes the Power switch controls or binding control
   interfaces from the board config

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate bindin

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_R
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters

   Removed the legacy FMUv4 define that was activating a nonexistent
   pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
   to VDD.

   Also detailed the connections of this pins for the board.

   The simplest connection is RC_IN to a timer capture pin
   and a UART.
   In this case the UART_RX pin and just be left as is.
   While the pin can be configured as the PPM_IN (Timer capture)
   or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
   facilitate binding.

  Renamed the macros and defines to be more explicit as to what
  Is being done and the sense of the parameters