Ability to report slog events from golang bridge

[mhofman]

What is the Problem Being Solved?

We want to be able to capture some structured log events (slog) from golang cosmos modules that are executed while handling SwingSet bridge messages. For example adding details about the paths modified during vstorage writes (to extends on metrics, see #10938)

Description of the Design

ReceiveMessage would created a context with a Slogger, and any x/v* module would be able to grab this slogger during their Receive handling to create slog event entries. These event entries would be added to the response.
The cosmic-swingset side would have to be updated as well to unwrap the response and separate the result from the slog entries (allowing for future extensions as well). We need to review as well how the chainSends are stored for hangover replay to only store the result and not the slog events. This likely means updating chainSend, and possibly changing how the chain sends are stored (parsed JSON instead of raw string)

Security Considerations

We need to allow slog events being out of consensus, and thus need to make sure any non-determinism is allowed and wouldn't cause a chain halt.

Scaling Considerations

All bridge sends already incur at least 2 slog events (for the syscall to the bridge device) and likely more like 5 when accounting for the necessary message to the bridge vat. The modules in golang are free to generate as many slog events as they wish, but should avoid doing anything proportional (keep O(1) messages per bridge send)

Test Plan

TBD

Upgrade Considerations

Requires a coordinated upgrade of the golang cosmos and js cosmic swingset bridge code. We can assume that during the upgrade all stored chainSend will simply be cleared and that we don't need the new version to handle what the previous version may have stored.