Generate bindings at compile-time

[dcoles]

This replaces the generate-bindings script with a build.rs script for flipperzero-sys that downloads the latest SDK and uses that to generate Rust bindings.

There's a couple of reasons for this change:

• Supporting multiple SDK versions (even after flipper-firmware-1.0.0 there can be incompatible SDK changes)
• Supporting multiple targets (currently we only really support the f7 target, but there is also a f18 build)
• Supporting alternate firmware (while not the primary focus of this crate, it should be a possibility)

[dcoles]

Uploading for initial review and testing.

Edit: Converting to Draft since the build isn't working on Linux.
Now building on Linux. 😀

[JarvisCraft]

I think that we should provide a way to build the crate offline from scratch.
Some build systems and distros (for instance, nixpkgs of NixOS) are quite restrictive towards internet access during the build phase and thus may be unlucky trying to build the crate depending on internet download during build.rs evaluation.

What I see as the requirement for this PR is a way to have:

1. Some default source of truth available with the crate itself (i.e. not requiring internet access during build).
2. Opt-in ability to override via local path (this can actually be enough to not implement point 1).
3. Opt-in ability to override it either via upstream flipperzero repo download (what you do in this PR);

So ideally I would like to see either:

Mode	Default	Envs (alternatively, a crate feature)	Behavior	Works offline
Pre-built	✅	None of the following	Uses something predefined, e.g. our pre-generated bindings.rs, as done now	✅
Local path	⛔ / ✅ (if we decide to get rid of Pre-built)	FLIPPER_SDK_PATH	Generates bindings from the local SDK installation	✅
Download	⛔	FLIPPER_SDK_VERSION, FLIPPER_TOOLCHAIN_VERSION, maybe explicit internet access opt-in flag	Downloads the SDK by the given coordinates (by the way, I suggest adding the ability to override BUILDS_URL for the sake of custom SDKs / forks)	⛔