WIP: Reducing PDDB dependencies

[bunnie]

The purpose of this branch is to reduce the number of dependencies on the PDDB so that it is easier to port it to new hardware platforms.

The original notion of the PDDB as designed for precursor was to minimize the number of dependencies that a password had to touch - this included all the I/O operations to get the keystrokes into the device. This meant integrating a lot of UX code into what would otherwise be a filesystem crate.

The cramium platform has a significantly smaller RAM footprint, but it is all entirely contained on-chip: this makes MITM attacks on RAM etc. much harder. In the case of this platform, the goal would be to minimize the total number of dependencies in the system, to reduce the code footprint overall, even if it means sharing UX resources for moving passwords and keystrokes.

This refactor is an attempt to line these two disparate feature requirements against each other. The two versions are selected by either using a "gen1" or "gen2" feature flag.

Here are the notes so far on the refactor:

PDDB will need a dependency on some sort of a "rootkey" crate. Probably, we will need to re-implement rootkeys entirely for each different hardware system, because the way the key boxes are handled is so radically different. Here are the features of RootKeys used by the PDDB:

• selection of an AES key at an index
• password entry to unlock key at index (this is handled inside rootkeys)
• key wrapping using the indexed key
• block decrypt/encrypt with the indexed key
• also queries are made with regards to the key box health and initialization status

PDDB also captures the UX flow for some key operations, such as formatting the disk, redoing the PIN, creating free space and so forth. If it were a platonic file system, I guess you'd try to turn these into "pure" APIs where you hand the PDDB everything it needs to do the specific operations on the filesystem. However, it feels strange to divorce such critical protocol-level code from the crate. So, I think the strategy will be incremental here - instead, let's rework "modals" to be more device independent:

• The work flow for many of the crates assumes we can have a blocking user I/O via the modals crate
• I think that the modals crate should probably be the "right" layer for things to talk to the UI.

Thus:

• Can we adapt modals to a small (128x128) pixel display?
• Can we adapt modals to a console-like text interface?

Strategy:

• Stop the refactor on PDDB at this moment and dig into modals/rootkeys
• Rootkeys can place the keys in RRAM at the "final" location according to ACRAM lock abilities even if the lifecycle stuff is broken, the ability to read/write those keys are configured "out of band"
• Modals should include an implementation directly inside the modals crate that pulls in the mini-gfx library, so that there are no other dependencies to get user I/O going.

The code as checked in is broken, but we'll come back to this branch once the other primitives are in better shape. Fwiw, as long as we don't select the PDDB crate as a cramium target, the cramium target still builds.