EKF introduce ecl_float_t type for double precision floating point where available (disabled by default)

[dagar]

PX4/PX4-Autopilot#12215

[dagar]

@priseborough @RomanBapst this adds the ecl_float_t type with a mechanism to set it to 4 byte float or 8 byte double based on hardware.

What's different now is it's completely disabled by default, but with a test fmu-v5 build (px4_fmu-v5_ecldouble). This will allow to to gradually evaluate everything in place.

[priseborough]

Sorry I missed this. It now has a lot of conflicts that need to be resolved. @dagar if you are able to resolve these, then I will review this as a priority item.

[lukegluke]

@dagar, isn't there a mistake - cosf()/sinf() will be used for double case too?

[dagar]

@dagar, isn't there a mistake - cosf()/sinf() will be used for double case too?

Yes that should ideally be handled as well, although my first priority was converting the bulk of the lengthy generated numerical code.

This actually stalled for a couple of reasons.

1. This change was actually quite slow (significant increase in cpu) on the current generation of stm32f7 processors that have double precision floating point units. I believe this is largely due to the the size of nearly everything doubling. If possible I'd like to try and identify the potential problem areas to more selectively perform the work with doubles.
2. At this point we'd still need to fully support ecl with single precision float for stm32f4. We can do it if there's value, but my concern would be nearly all developer and testing activity focused on the newer boards, inevitably leading to subtle problems only on stm32f4.

[priseborough]

This has bit rotted by a lot. The ability to use double precision is something to aim for given HW development roadmap.