Migrate to betaflight build system

[martinbudden]

Migration to the betaflight build system offers (at least) the following advantages:

1) Faster travis build time 2) Having the same (or nearly the same) system as betaflight reduces maintenance 3) Makes it easier to pick up betaflight build optimisations (eg STM32 low-level libraries, F7 build options etc)

[fiam]

While the ßF system with multiple Makefiles is faster and cleaner in some aspects, I think it still has some problems.

For example, headers are pulled from ./lib/main/STM32Fx/Drivers/CMSIS/DSP_Lib but the code in .c files is compiled from lib/main/DSP_Lib/. I guess I don't need to elaborate why this is such a bad idea.

There are also a lot of duplicated files to simplify the build rules a bit, which in my opinion is not worth it. I'd rather see a couple more include paths in the CFLAGS than having the same file in 5 places.

We also need to take the settings generator into account, since ßF does not use it (maybe we should submit it to ßF?).

Since all these issues except for the settings generator would benefit ßF too, I think it makes more sense to fix these problems in ßF first, then move INAV to the ßF build system.

[fiam]

Regarding the toolchain integration with the build system I think it's nice that the build system automatically downloads the compiler for you, but I also think it should be easy to override.

I would go as far as introducing a tristate variable:

a) Use system compiler if found, fallback to bundled toolchain (the default) b) Use the system compiler, fail it not found c) Ignore compiler already installed and use the bundled toolchain, downloading if it needed

[DzikuVx]

@digitalentity did you just did that few weeks ago?

[digitalentity]

Not exactly Betaflight's build system, but quite similar. I guess we can close this.