Migrate swing-store shadow copy to x/swingset cosmos store

[mhofman]

What is the Problem Being Solved?

#7225 introduced support for state-sync, leveraging the existing vstorage API to store a copy of the swing-store in the cosmos DB.

However the semantics of the vstorage API are not the best fit for large amount of data which are actually never consumed by off-chain clients. Amongst other things vstorage uses an encoding meant for direct children enumeration which makes it expensive to iterate over all entries as needed during state-sync operations.

Description of the Design

• Introduce a new Prefixed KVStore in the x/swingset module used for holding the "export data" of the swingstore
• Register a port handler for the x/swingset module, and add a new bridge API for stream exporting swing-store data into this new cosmos store.
• Update the state-sync logic to use the new store when restoring
• Add migration logic to place existing swing-store data in the new cosmos store

Security Considerations

None. The new DB is part of the same overall cosmos multi-store, which is similarly hashed under consensus

Scaling Considerations

This is a performance improvement, mostly when performing state-sync restore, but also when streaming swing-store data into the cosmos store.

Test Plan

The existing integration test should cover the state-sync logic
The docker upgrade test should cover the migration
Add new unit tests for the new x/swingset prefixed store