A stab at API for patching one type into another

[Tisten]

Related to #148

This is an API proposal for patching data from one format into another. It lacks implementation right now, so I would not be surprised if it changed slightly, but I want feedback before starting on it.

I refer to the process of "adding and removing members, changing member types and moving ordering of members" as patching, as in "lappa och laga", instead of converting as you did in discussion of issue 148. Mostlybecause there is a dl_convert which deads with endian and pointer size. We are mostly using it to iterate on types and upgrading/patching the data from one old type definition into a new one. Up until now we haven't don't any big data migration where a real conversion/transform of the meaning of the data happened.

I have thought a bit about trying to patch the data in-place, but it will be error-prone since the data always need to shrink (which is rare) and it adds a ton of complexity so I skipped it entirely in this first iteration.

I am however considering how patching is going to be used most commonly. Will it be during unpacking the data to use it directly after, or will it be more common to upgrade data on disk and resave a packed version. I.e should the patched result be packed or unpacked, and how important is it that all pointers are stored in continuous memory if it is unpacked?

When you reason about this API please keep in mind how the any_pointer and any_array types will influence the usage of the patching. These types are not seen from the root instance, and a "pointer patch" will work just fine without knowing the type. Getting the pointer to the root instance requires knowledge of the alignment, so the instance_load will fail if the root type has changed (also assuming dna hashed types which is what I'm using).

I am guessing that you would prefer to patch into user allocated memory over the current linked list of pointers to free, and I think I will swing in that direction too once I start implementation...