Update Build System and Remove Symbolic Links

[TravisWhitaker]

In summary, this PR suggests the following changes:

• Remove all symbolic links from the project.
• Harmonize conventions for the structure and definition of header files and their relative installation paths.
• Rewrite the build system so that its behavior is clear and explicit, rather than implicit and difficult to refactor and maintain.

The presence or absence of symbolic links to inconsistent subsets of the "driver" directories was previously used to convey to the build system which translation units should or should not be compiled for a given target. This constitutes an implicit definition of behavior, is a pain to manage, makes the project structure less clear, and has the potential to present cross-platform headaches. The new build system favors explicit and declarative definitions.

The previous build system was not sensitive to the build artifact dependency graph (caused in part by the use of symlinks, which confuse make). This build system makes use of compiler-generated makefile fragments to construct an exhaustively transitive dependency graph of all artifacts. "Cleaning" should never be required, and if it is required to fix a build after a change, this should be considered a bug in the build system. The declarations in the specification convey the same information as the old symlink presence/absence conventions, but do so explicitly and in a single, easily updated location. The new build system implements all functionality of previous makefiles, including flashing Osmium to the device.

Through this exercise an effort was made to minimize ancillary changes to the directory structure. This was largely achieved, and the two changes that were made arguably improve the clarity of the project structure. The first change involves the targets directory that exists in each driver directory. In order to simplify dependency scanning, every target was given a (potentially empty) shared directory.

The second change involves the include directory present in each driver directory. In every case outside of the driver directory, where an include directory exists, that directory is rooted at the top level of the flipper header file hierarchy, i.e., each one also contains a flipper subdirectory. This inconsistency was corrected, leading to the following benefits:

• Simplified dependency scanning.
• Simplified construction of transitive dependency graphs.
• Project-wide consistency, all include directories now share the same implicit root.
• Simplified installation, simply union all include directories into PREFIX/include. No messy simlink handling.

I've tested all functionality on Linux. All binaries generated are identical to the old build system. The only caveat is that my test for burning Osmium is somewhat vacuous; the same arguments to flipper and avrdude are used, but without hardware I can't actually test the process.

The build system interface is essentially identical to make and supports the flags one would expect. To use the build system, install GHC and Cabal, run cabal update, then run cabal install shake. Navigate to your flipper directory and simply run shake, which will build the default targets as you'd expect with make. shake -jN runs N jobs simultaneously. Shakefile.hs can also be used as a standalone program, i.e. via ./Shakefile.hs and accepts the same arguments. Specific targets are invoked as you'd expect, e.g. shake install will install libflipper and the flipper console, just like the old build system.

Let the bug-finding begin.

[georgemorgan]

This is going to be fucking awesome. Let's make shit happen and give the world an embedded system unlike it's ever seen before.

[TravisWhitaker]

Neat. Things seem to be mostly working with Xcode. As long as an IDE works by simply checking if each line of stdout is a compiler warning/error, things should integrate pretty seamlessly.

[harlanhaskins]

stderr*