refactor(neon_framework): use a separate persistence layer backing th…

[Leptopoda]

…e storages

The general idea is to decouple the storage layer, the app is talking to, from the layer actually persisting the data.
A Persistence is just a basic CRUD like (maybe asynchronous) interface for the storage layers to use. Other implementations like the CachedPersistence cache the data in memory (HashMap) so reads can be synchronous while writes are asynchronous in the background.

In turn we can build a complete SharedPreferences implementation on to of the cached persistence. Currently the SharedPreferencesPersistence is just a CachedPeristence warper around the shared preferences (with some key handling magic to allow the current data to seamlessly be used without any migration).

I understand that the current default implementation of our storages (SettingsStore and SingleValueStore) are already wrappers themselves but with the up cumming migration to a SQLite persistence we will no longer have the double wrappers. This may seem like a lot of unnecessary boilerplate interfaces but as shown in #1585 it will allow us to make changes with minimal effort.

We can later consider changing some of these patterns but it was the easiest way to tackle it in a reviewable small patch-set.