Atomic storage API rework

[JonathanArns]

Please make sure these boxes are checked, before submitting a new PR.

• You ran the local CI checker with ./check.sh with no errors
• You reference which issue is being closed in the PR text (if applicable)
• You updated the OmniPaxos book (if applicable)

Issues

fixes #97

Breaking Changes

This is supposed to be a major rework of the storage API (and everything that entails, likely touching a lot of places in the code), with the goal of enabling truly atomic storage implementations. The idea is described in the above issue in more detail.

We will try to stay almost compatible with existing storage implementations, by providing a sort of compatibility layer that can provide basic atomicity for non-atomic storage implementations.

[JonathanArns]

So far all that has been done here is that @kevin-harrison and I drafted how the storage related types might look in the future.
At least NonAtomicStorage will likely need to change a little more, in order to hopefully accommodate rollbacks of log operations (append, trim). We should of course try to stay within the bounds of what is reasonable to implement in the context of an append log (so we don't enforce super-slow implementations in some way).

[haraldng]

Superseded by #121.