Allow running MIRI

[JarvisCraft]

Introduction

While some Flipper abstractions are easy to port to Rust, some have complicated lifecycles and are tricky to be wrapped in safe abstractions. Current work done in #29 is an illustration of this point.

---

The most common problems appearing are

Aliasing

Arguably, the most complicated and still volatile part of Unsafe Rust especially painful when ahving to work with APIs which originally provide shared access (first of all, callbacks).

This is also especially tricky artound Box-based allocations for which there are uniquness guarantees at some point.

Concurrency & mmulti-threading

When and where do we have to insert synchronizations for soundness?

This is specifically important for callback-based APIs.

Extern type trickery

See rust-lang/rfcs#1861 for what we may need ideally.

We may want to create formally unsized wrapper-types of form

#[repr(transparent)]
struct Foo {
    // this should be an extern (thus unsized) type
    // making this wrapper unsized
    raw: sys::Foo,
}

which would only be usable via pointers (and their derivatives, i.e. references) safely transmutable to/from raw pointers.

---

In order to facilitate the creation of such abstractions, more tools could be used.

Description

We should try allowing the usage of MIRI in the way similar to how the tests are run currently.

This would give us a chance to catch some errors inm wrapper implementations.

[str4d]

We're going to have a very hard time of this, because Miri doesn't yet support arbitrary FFI calls. I've locally made changes that enable MIRI_NO_STD=1 cargo miri test --target thumbv7em-none-eabihf to at least run into this issue:

error: unsupported operation: can't call foreign function `furi_record_open` on OS `none`
   --> /path/to/flipperzero/crates/sys/src/furi.rs:112:19
    |
112 |             data: crate::furi_record_open(name) as *mut T,
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't call foreign function `furi_record_open` on OS `none`
    |
    = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support

but given the sheer quantity of FFI calls we have, I don't think we can reasonably expect to mock them all out for Miri.

[str4d]

Aha, I missed the -Zmiri-extern-so-file=<path to a shared object file> experimental flag. So Miri does support at least simple FFI calls that only have integer (or void) args and return. That won't help for the majority of the FFI calls in the Flipper Zero SDK though, which operate on pointers.