This reverts commit d6df692b.

The changes to attitude controller improve this a lot.

If you want to go to the limit of what the vehicle can do, you need to be
able to set it so large that it is guaranteed that it's never limited by
software.

Tests showed that it's not a problem to increase it to very high numbers.

360 is too fast if you just want to hover. Next step is to add expo(),
so that we still have fine-grained control at the center and high rates
at the edges.

Previously, the yaw weight was based on the tilt angle of the attitude
setpoint (R_sp(2, 2) == cos(tilt angle)). This makes no sense, it means
the weight is low for high tilt angles even if there is no roll-pitch error
at all.

This patch changes the weight computation to be based on the tilt angle
error: the yaw weight is 1 if there is no roll-pitch error (independent
from current tilt angle), and is reduced for higher tilt angle errors.

The weight was added in 05e9a305, without any explanation or
derivation of how and why the weight is chosen that way.

However this patch works much better in practice. The yaw control is
improved, though it can be a bit slow to converge if you do continuous &
fast roll-pitch motions (which is expected).

No semantic changes.

The feedforwarding was applied in the wrong frame: the term is given in
global coordinates, but was directly applied to body coordinates. This
patch adds the missing transformation from global to body frame.

In addition, it moves the feedforwarding before the rate limitation, so
that we cannot exceed the configured rates.

It's not necessary to do this computation in each loop iteration.

It was setting the rotation value to the I2C slave address
causing it to not be successfully probe.

Changing the constructor paramters order instead of
just fix line instantiating to keep consistency with
the other lidars and sonars.

Depending on the CMake version when we are configuring it emits a
warning about deprecation of CMAKE_FORCE_CXX_COMPILER. However we
rely on this macro and don't want to do what CMAKE_CXX_COMPILER
is doing. Here is what I get with CMake 3.9.1:

	CMake Deprecation Warning at /usr/share/cmake/Modules/CMakeForceCompiler.cmake:83 (message):
	  The CMAKE_FORCE_CXX_COMPILER macro is deprecated.  Instead just set
	  CMAKE_CXX_COMPILER and allow CMake to identify the compiler.
	Call Stack (most recent call first):
	  cmake/toolchains/Toolchain-arm-none-eabi.cmake:37 (cmake_force_cxx_compiler)
	  /usr/share/cmake/Modules/CMakeDetermineSystem.cmake:94 (include)
	  CMakeLists.txt:263 (project)

Avoid the warning by passing -Wno-deprecated to cmake.

   Tied to nuttx, apps  px4_firmware_nuttx-master
     rebased on upstream nuttx master @ 3647ace55958c094cfe93f07092d308a768f5ca3
     rebased on upstream apps master @ 21c9b793e2ca6f4e86388c80d7af5c466de5e71c

   Latest nuttx 7.22+ with PX4 contrib for stm32 f4 I2C hang.

  Prep for Nuttx Upgrade - still needs i2c fix

   board_adc_init()    - initalise the ADC HW once.
   board_adc_sample()  - read a given channel dn

   Internal functions are public functions that should realy only
   be called by the board config.