NVRAM support

[williampMSFT]

(Discussion)
I'm currently working on a trait to abstract access to NVRAM storage (e.g. storage provided by real-time clocks, eight 32-bit registers on the hardware platform I'm prototyping on). During the review for that, it came up that this might be something that would be useful for embedded-storage - is there any interest on your end in us potentially migrating such a thing here?

As currently implemented, the trait I'm proposing has a size known at compile time because of how limited space is on these RTC modules - this lets you ensure at compile time that you're not overcommitting storage, but it's a bit different from the existing traits here where you're expected to interrogate the trait for how much storage is available at runtime and handle failure / out-of-bounds. Is extremely-limited-space (to the order of tens of bytes) storage in scope for this crate, or is this more intended for mass-storage?

[eldruin]

Thank you for the proposal.
I think it might be a good addition. What do you think @MathiasKoch ?

[MathiasKoch]

I wouldn't be opposed to it.
I also don't have any use for it myself, but I think the whole idea of these repos & traits is to attempt to establish easy-to-find and adopt interop rather than everyone creating their own abstractions, and with that goal in mind, I think it makes sense if the trait is designed in a way that allows generalized usage from both implementor and consumer side (I cannot judge this, as I have never worked with NVRAM)