Add wrapped and unwrapped to authority store and signed effects

[lxfind]

In #406, we added support to tell when an object is being deleted in a transaction (through a DeleteObjectID event). But we were not processing this event.
This PR uses that event, so that we could tell which object is being deleted and which is being wrapped (similarly, which is being created and which is being unwrapped).
There are two reasons we want to distinguish them:

1. Clarify to the users. Users will find it confusing to see their objects deleted but in fact they were just wrapped; similarly it's confusing to see an object being created, in fact they were being unwrapped.
2. More accurate information on the authorities, which will allow us to return more accurate information regarding the latest state of an object (wrapped instead of deleted and etc.). It will also allow us to delete objects from the store if they were really deleted.

Specifically, this PR does the following:

1. In adapter.rs, we now process the object id deletion events, and add them to a list. Based on the list we can construct a more accurate story on object deletions. There are 3 types of deletions (defined in DeleteKind): ExistInInput means objects that were in the input and being actively deleted; Wrap means objects that were in the input and being wrapped; NotExistInInput means objects that weren't in the inputs, but seems to be actively deleted (reasons on why this could happen are in the comments).
2. The addition of these deleted ids that are not in the input has some consequences and need to be dealt with while patching up the unwrapped object versions.
3. Add wrapped and unwrapped to signed effects, create them properly.
4. Update the authority store with the accurate digest.
5. Added a detailed test on the version and digest for wrapping and unwrapping.

Closes #588.

[velvia]

Will have to come back later on this, it's a big review and most of the rest of the code I'm not familiar with. :-p

[velvia]

This objects is the temp store, that would have a copy of objects that are deleted?

[lxfind]

It won't. The temp store gets objects from two ways:

1. if the object was in the input of the transaction
2. if the object was written during the transaction

For an object that was wrapped in the past (i.e. embedded in another object), and got deleted in this transaction, we will not have the object content anywhere (except inside the object it was embedded in).

[huitseeker]

This LGTM, I left comments to improve the rustdoc. I wouldn't be that nitpicky usually, but I think they would help here in letting the reader jump to parts of the code that define invariants that work with each other.

Another way to address this need to "read it all before you modify one part" in metadata is to use stg like pre, but the rustdoc is perhaps more reasonable in this instance.

[huitseeker]

I must admit this is a bit terrifying, but I don't have much of an alternative, except for an imbricated pattern match that the unpack makes unwieldy, so ...

[lxfind]

I will clean this up in #675.