Data storage

Outline:

1. So we always store the type when serializing under a separate key (==_$!!object_class)
2. Each class that can be serialized can (must?) implement an interface that offers custom (de)serialize methods to a Chunk (the types are written when serializing) and a method to set the version.
3. You can register migrators that convert from one version to another and will be chained by the system as needed.
4. When deserializing the object is constructed based on the types and if the version mismatches, all fields will be deserialized and the migrator is invoked.
5. Serialization is not done against ConfigurationSection but against a Map-like datastructure (Chunk) that allows accessing nested keys easily via a dot in the path.
6. You can register Proxies that serialize from/to a Chunk. These are used to serialize types you have no control over as well as provide an internal mechanism to store maps/collections.
7. Backends are tied to a file from which they load and save from
8. Managers get data from backends(new name needed?) via a key (new interface needed for this!). A single file backend that just loads an entire file in memory and treats it as a Map and a multi-file backend that takes a folder and treats each key as a relative path is provided.

Problems:

1. Backend has two meanings:
   1. JSON/YAML/WHATEVER storage
   2. Key-Value store that is queries by the Managers
2. Anything else?