[Feature Request] Make VM parametric in event format

[sblackshear]

To support user-defined events emitted during execution, the VM keeps a Vec<Event> log, where Event as defined as

pub type Event = (Vec<u8>, u64, TypeTag, Vec<u8>)

here. In this representation, the event's user-defined type is in the TypeTag and the event value of this type is in the Vec<u8>.

However, there's no reason why events must have this structure--conceptually, the VM could just as easily allow the adapter to choose the structure of Event. This would be useful for an adapter we are currently working on where events look a bit different, and I expect that future adapters will find other uses of events that might not want to use this structure.

Note: the Move stdlib has an Event module and accompanying emit native function that do rely on the structure the VM assumes. We should think carefully about how we want to handle this. One option is splitting out a part of the Move stdlib that is fully generic and would be used by every conceivable adapter (e.g., Vector, Signer, Option, BitVector, ASCII, FixedPoint32). But that's a topic for another issue.

[tnowacki]

Why are events in the VM at all? I thought we split this out when we fixed up the native function work? @vgao1996

[vgao1996]

@tnowacki we designed our native functions in a way such that they could support generic events relatively easily, but

1. didn't remove the old events (incl. vm implementations and native functions)
2. didn't implement the tweak that would actually allow our new native functions to emit events

[sblackshear]

I think keeping events in the VM makes sense--I'd expect them to be a common feature across most adapters (and there's no harm having them there if an adapter doesn't want them). But I'd expect many adapters to want to make different choices on the format of events. E.g., the adapter we're working on doesn't have the GUID or event sequence number parts that the VM's current format expects.