improvement: first shot at serialization / deserialization

[davidedc]

Implemented a first draft of serialization / deserialization. It works on a morph. The morph can be complex (e.g. be a frame with multiple inspectors inside), but for the time being it needs to be self-contained to be functional (e.g. no references to morphs outside the hierarchy of the selected morph).

Since JSON doesn't handle closures, quite a lot of refactoring was needed of the callback system here https://github.com/davidedc/Zombie-Kernel-core/commit/c33275e31ca1631b44664f423ae2a6389208afe2 and here https://github.com/davidedc/Zombie-Kernel-core/commit/da0d3d2c18c1e93b28581d39fb0ca825eff85006 . (Closures in callbacks can be just transformed into "normal" method and accompanying parameters to be passed at call time).

Serialisation now hinges on a more generic deepCopy mechanism which replaces the previous "fullCopy" implementation here https://github.com/davidedc/Zombie-Kernel-core/commit/3e7dfee1676da9e61e31d6af4efdd3f205b09f9d .

JSON doesn't handle cyclic data structures, or preserve the identity of shared references (i.e. two references to a single object will be restored as references to two equal, but not identical copies), so some work was done to cater for both here https://github.com/davidedc/Zombie-Kernel-core/commit/6a636439af59fa1606877237e150d58904d816b0

Improvements will follow to a) allow for "notable" references to Morphs outside the hierarchy of the selected morph (e.g. references to the world morph) b) letting Morphs to pre-process and post/process their state before/after serialisation as they see fit (e.g. to discard transient data that can/should be recalculated, etc.)

Little example animation of one of the tests is attached, note that serialisation / deserialisation at the moment can only be triggered via the console - proper menus and export to file will follow. A frame here is created containing a rectangle and its inspector. The frame is serialized, the world is cleaned, then the frame is deserialized and lastly it's added to the world. All buffers and references work fine.

Note a little glitch: in the deserialised frame, the inspector still has the label containing the ID of the original rectangle (#1), even though it's correctly pointing to a second, new, independent rectangle (#2). In the next iterations the Inspector will have to be given a chance to update its contents based on the state of the new world it appears in...