WIP: initial support for fixed-point data for sensors

[raiden00pl]

Summary

WIP code for fixed-math data type for sensors.

All sensor math operations will require modification to use sensor_data_xxx macros.

At the moment, no sensor is modified to handle this properly. I'll probably choose the easiest sensor to port with a small amount of math operations to provide PoC.

EDIT: ported bmp280_uorb to fixed-math, probably the easiest one :)

Ultimately, all sensor units must be checked to see if the data unit make sense for the b16_t type.

Doing this work all at once is a lot of work which I don't want to do, so I suggest introducing this change gradually:

1. introducing a configurable sensor data type and raise compilation error in all sensors that don't support fixed-point data type
2. gradually port sensors to use fixed-point data and remove compilation errors
3. on the app side we need to modify uorb tools to work with fixed-point data. At this moment we can just raise compilation error for fixed-point data type, and add depends on SENSORS_USE_FLOAT

Impact

Testing

[linguini1]

One more thing about this; we should investigate if b16 is ever too small for a sensor's resolution. I would imagine float might have this same problem when compared to double for high-resolution sensors, but if there are any values that would fit in float and not b16, we should consider:

a) having those sensors depend on the float representation, so users can only use them with floats
b) allowing the user to choose b16 vs b32 (and maybe also float vs double)?

What do you think?

[raiden00pl]

It would be best to choose sensor units that make sense for both float and fixed-point.

With this architecture it should be possible to add other data types for sensors, but using 64-bit data seems like a overkill to me. So far, the highest resolution of data in commercial available sensors that I have seen is 24 bits.