Add Support for External MemoryUnits

[jhbruhn]

Currently the Library only knows one Internal MemoryUnit. Support for at least one (if possible, more than one) MemoryUnits like an external Flash/EEPROM for Update storage would be handy to easily support Hardware Setups where the MCU Memory is already used completely.

[jhbruhn]

I have been thinking about the MemoryUnit-situation. We can either:

• Abolish the use of the embedded_storage traits, and fork them to also take MemoryUnit into consideration.
• Remove MemoryUnit and let the implementer of the embedded_storage trait do the heavy lifting by mapping certain address ranges to different units of memory, as is the convention with typical MCU memory models.

Originally posted by @Wassasin in #2 (comment)

[jhbruhn]

A third option would be to pass a Storage unit for every MemoryUnit. This is simple as long as we only distinguish between one Internal and one (optional) External MemoryUnit, but gets more complicated as soon as there are more than two different MemoryUnits (e.g. when using two external memories).

Is the use-case with two different external memories realistic? If so, I propose we either

• replace MemoryUnit with a number (u8 should be enough) indicating which memory to use (not very ergonomic)
• make MemoryUnit have an Internal() and External(u8) value, where External(u8) addresses the n-th external memory

Both of these are pretty complicated and still not as ergonomic as I prefer.

About your ideas:

1. I wouldn't want to abolish/fork the embedded_storage traits, as they will make usage of an external memory with drivers implementing the traits very easy, in addition to the handy NorFlash implementations
2. Having a manual memory map would make it easier for moonboot, but part of my goal with this project is to make usage of the framework as ergonomic as possible (as in, integrated into rust code, if possible "autogenerated"). See for example the generation of linker scripts. Making the consumer of this lib manage a virtual memory map in addition to the microcontrollers memory-map would make things more complicated.
   We could of course use such a memory-map internally and put an abstraction layer over the external API, but that complicate things even further I think.