Generate mxcfb structs with bindgen

[bkirwi]

The new AppLoad launcher has a libremarkable-specific shim to deal with the fact that some of the newer remarkables are 64-bit apparently, but this code hardcodes 32 bit in a few places.

Instead of cleaning this up by hand, this PR uses bindgen to automatically translate the C headers. It's not perfect (some function-type macros don't get mapped over, for example) but maybe it's better? Let's see what CI thinks.

[fenollp]

Sounds good to me!

• please move the yaml fmt changes to a separate commit, so review is easier
• looks like CI fails due to a missing apt install libclang-dev

[bkirwi]

Heh, I was hoping it wouldn't email anyone until it's out of draft. 😅 Glad it makes sense though! I'll follow up here when it's ready to go.

(The last build failure is interesting - it's because libclang is out of date in the standard cross image, I think, so installing clang in the runner doesn't help. I've updated the runner on one of these before but not for a long time... should be an easy fix once I refresh my memory.)

[bkirwi]

Mmm... and it turns out that the most recent release of cross is now old enough that it can't pull in a sufficiently recent clang to meet the minimum requirements of a contemporary bindgen. Annoying!

I could use a custom image, maybe one of the toltec ones, but I'm reconsidering the approach: it seems valuable for libremarkable users to be able to use cross without jumping through horrible hoops. (But maybe bindgen is common enough in Rust that we expect users to need to bite that bullet anyways?) Anyways will reflect.

[bkirwi]

The last commit is an attempt using the toltec builder. It requires overriding some env vars to point to the proper sysroot etc., but otherwise it works reasonably well.

The main thing it does not do is support cargo test, since that relies on qemu which IIUC is baked into the cross images but not the toltec ones. (Maybe there's some way to work around this, but I think it's past where I can go for a quick experiment.)

It does make me wonder if we can prebake an image that has all the cargo environment variables etc. set up properly, like cross does. But that's probably something to shake out elsewhere...