Non-`'static` Allow and Subscribe API design (tracking issue)

[Johnathan Van Why]

For Ti50 and Manticore, we need an Allow API design that supports non-'static buffers. It would also be preferable to support non-'static Subscribe callbacks, in order to produce more idiomatic Rust code.

There are multiple designs that might work for this API. To avoid confusing the different designs, I suggest we put the designs into separate issues (or separate PRs as submitted documentation). This issue is to discuss requirements for the non-'static Allow and Subscribe APIs, and to link to other discussions (such as issues with specific designs).

I believe the requirements for the APIs are as follows:

1. Support both Read-Only Allow and Read-Write Allow on buffers on the stack.
2. Support Read-Only Allow for buffers in read-only storage (flash).
3. Support multiple concurrent operations. An use case is cancellation: e.g. "read from the console unless interrupted by a button press or timeout". An additional example use case is flashing lights while an operation is ongoing (e.g. while waiting for a USB message).
4. Have a safe API that is sound. It should be possible to implement the drivers without using unsafe.

Additional nice-to-have requirements are:

1. Avoid relying on dynamic memory allocation.
2. Avoid relying on any unstable features.
3. Support drivers written in idiomatic Rust. While extensive use of interior mutability works, it is not ideal and not the preferred option.
4. Support 'static buffers and callbacks as well (to avoid needing separate 'static APIs).

And as always, code size and RAM usage are priorities as well.

WIP solutions

Here are the designs we are currently working on:

1. #338
2. #341

[Johnathan Van Why]

Note: I separated this from #334 because #334 is about APIs that support highly-asynchronous codebases that look similar to the Tock kernel, so the existing discussion is not relevant to the design of this API.

[Johnathan Van Why]

For now, I think I'll go with the Pin<>-based design described in #338 . We can replace it later if we find a better design, but I want to get a Tock 2.0-compatible libtock-rs out ASAP.

[Johnathan Van Why]

#338 was unsound, but I was able to ge the design from #341 working and merged.