StaticBuffer initial design

[DanutAldea]

This draft tries to solve the issue of sharing Read-Only static buffers with the kernel by introducing an initial design for a StaticBuffer handler that uses the same design choices made by the full_dynamic module.

• fully dynamic IDs
• runtime tracking of allow state

The allow tracking mechanism (ShareInfo and unshare functions) to save some memory.

[jrvanwhy]

Is it fine if I merge this PR? I know it's in draft status but it seems worth having.

Reading the files/ view in this PR made me realize that the number and size of disassembly files has grown, and I no longer want to have them included in tock#5. To avoid bloating the repository history, I'm inclined to remove them, add the disassembly/ directory to .gitignore, then amend my commit and force push. However, I think that will cause a merge conflict. What I'd like to do is:

1. Merge this PR to add it to my allow-pin-size branch.
2. Remove the disassembly/ directory and .gitignore it.
3. Squash everything together into one commit.

Are you fine with that?

On the API design side, it's not clear to me how an API should accept a buffer to use. For a concrete example, what would the "write to the console" function signature be? I think we would need two functions (or a generic function that generates these):

/// Writes to_write to the console.
fn console_write(to_write: Pin<&mut Buffer<[u8]>>) -> Result<usize, ErrorCode>;

/// Writes to_write to the console.
fn console_write(to_write: Pin<&mut StaticBuffer<[u8]>>) -> Result<usize, ErrorCode>;

I have some ideas on how to handle that, and I think I can help prototype that once we figure out how to merge this PR.

[DanutAldea]

Hey!

Merging this PR is fine by me. I'd be glad to help once you have a prototype. I the meantime, I will also give it some thought.