Allow structure sharing of objects belonging to more than one item's implementation.

[sageserpent-open]

This is related to #44, only this time we might want to support sharing structure between distinct items where an event pulls out some objects from one item that belong to its implementation, and then provides them as arguments to a mutator on another item that causes that item to acquire references to those objects.

I'm not absolutely sure that this should be supported at all - this is the kind of thing that functional programming purists regard as a downside of object oriented programming (at least the kind that is seen in real life code) where both items are now vulnerable to mutations of the shared object made by each other. While that could be regarded in some cases as a good thing (think of retrieving an object from a cache and mutating it as a form of information propagation), in general it is a sign of sloppy programming - usually either a badly designed API or the Law of Demeter being disregarded.

That would also open up the question of policing of writing pure functional code for queries, which currently is only policed at the level of items, not for the objects that own or create.

[sageserpent-open]

Revisiting this, I'm leaning towards the strict model of treating any non-identifiable objects passed to or returned from mutations (and queries) as being treated as immutable state, and that this should be policed.

Furthermore, two of the implementations force this to happen anyway by effectively cloning shared object state between identifiables as the latter are converted into blobs; so what should be done is to detect the execution of code that attempts to mutate such shared state.

Of course, mutators should be free to mutate any object that is part of the transitive state of the identifiable being mutated.