Add abstraction for storing persistent variables

[PatrickKa]

Description

Persistent variables are part of the persistent state. They are very important because they contain things like the activeFirmwareImage. Therefore, they should be implemented with a self-healing mechanism. I suggest storing each variable three times on the FRAM and every time a variable is read the three values are compared and a potentially wrong value is overwritten.

There must also be a way to easily place multiple persistent variables one after the other on the FRAM without overlapping and manual address calculations.

[PatrickKa]

Blocked by #185 and #192

[PatrickKa]

We should also add a counter that is incremented every time a persistent variable needed to be repaired. That counter should probably also be a persistent variable, so get()/load()/whatever should also return whether a repair happened or not.

Edit: We don't have time for this additional complexity, and the test memory section of the FRAM can give us similar if not better information anyway.

[PatrickKa]

We also need to make sure that all persistent variables are repaired often enough such that only a single one of the three redundant copies of the values gets corrupted by radiation.

Edit: I think all (or at least most) of the persistent variables are part of the telemetry data/beacon, therefore they are accessed every 30 s which surely is enough.

[PatrickKa]

As explained in #294, we need a fallback mechanism in case the FRAM does not work. This means that every persistent variable also needs to cache the value three times in RAM. If the FRAM works, data is read from and written to it. The data is also always written to the cache, but only when the FRAM doesn't work is it also read from the cache.