Structure overhaul #11

Having used Preserve for a while now, we've collected a bunch of changes that are going to require a pretty significant change in structure, but allow a lot more flexibility in how Preserve can be used. This will be pretty much a rewrite, bumping up to v0.4dev.

Most significant change is probably moving all configuration and registration of Preservables into dicts stored in the preserve module. Preserve should no longer touch or modify any of the classes registered or decorated as preservable.
The existing enum based RestoreMethod system will be tossed, in favour of a more generic system where each preservable can specify a callable to be used for the preserve and restore operations.
To do this, we're going to save a bunch of records - one for each preservable - that hold the type of the object, the name to be used as a metadata key in the preserved output, and the preserve and restore methods to be used with it.
The list of types to be passed directly through will now just be a list (that can be changed). dict and list will still have special treatment (both mutable and can contain other objects)
As well as adding the flexibility of generic methods, we'll add the ability to pass some of the args to the @preservable decorator via class attributes. This allows subclasses to inherit the preservable behaviour of their parent if they choose to.
We'll work towards providing a set of Preservable implementations for common classes and types
Some more thought will need to go into the preserve output protocol and how metadata other than just the type name is stored.

Ideally all of these would be implemented in nice little self-contained commits, but changing the structure so drastically probably isn't going to be amenable to that.