Generate C bindings from dwarf metadata (continued)

[nicholastmosher]

This is a continuation of #115 which accidentally got merged early.

Previously, the C template didn't actually return the value received from lf_invoke, in addition to doing unnecessary and sometimes invalid casting and assignment.

Additionally I've bumped the console version to v0.1.2. I think we should continue to do regular version bumps when significant features are added.

@georgemorgan I've been a little confused as to the state of how modules should be generated. One outstanding question I have is whether modules are going to be one-file (module.c) or whether they'll also each require a header (module.h). We'll talk at some point and make any necessary changes then.

[georgemorgan]

Modules will be one file for now. It looks like what I wanted to do is not possible for now, so we will have to stick with the separation of the host and device code.

Modules will be generated as they are now, with the LF_MODULE(...) macro and the jumptable struct. It would be helpful if you could implement this, as I am not as familiar with the setup. Build the example app and see build/flipper/binding.c for the structure, or look at fdwarf.py. If you can't build the example, please open an issue for @kjcolley7.

[nicholastmosher]

When I go to rebase this against master I'm having all of these tests fail. So I want to put this one a little on hold and get #112 merged first. We'll have to change this one to be version 0.1.3.

[nicholastmosher]

Status update. As of the latest commit, the CLI for module generation is

flipper generate /path/to/module/binary [-o output/path], where the -o flag is optional and places modules into the current directory by default.

Also, I introduced logging here to provide visibility into when certain subprograms or parameters are skipped during parsing. To see them, run

RUST_LOG=flipper_console=warn flipper generate /path/to/module

[georgemorgan]

What is the status of this PR? Is this stale?