fix(swing-store): move getAllState/setAllState onto a debug object

[warner]

getAllState and setAllState are swing-store helper functions which copy (or set) all the state of a store at once, used exclusively for testing.

Previously, they were exported by swing-store, and applied to a kernelStorage object, but that depended upon a
streamStore.dumpStreams method that we'd rather not expose to normal users.

This commit adds a new debug object, next to kernelStorage and hostStorage, which holds getAllState, setAllState, and dumpStreams. The kernelStorage.streamStore object no longer has a dumpStreams method.

This also updates all the swingset unit tests which were using the helper functions.

[FUDCo]

This looks good, though merging with the swing-store changes already in flight might be a pain, which raises a question of whether snapStore-then-debug-hooks or debug-hooks-then-snapStore will be the lesser merge effort. I'm going to withhold approving until we answer that question, so that unexpected automation doesn't do something prematurely, but the changes here themselves seem just fine.

Related to all that, I'm wondering are we going to want or need something analogous to dumpStreams for the snapStore?

[warner]

I'll rewrite this on top of #6781 before proceeding. @FUDCo pointed out that what we really want is a programmatic form of /usr/bin/sqlite3 swingstore.sqlite .dump, since this API doesn't need to be editable or deterministic (or fast, although .dump is pretty fast). I found some pointers on using the built-in sqlite_schema table to accomplish this: this table includes a row for every table/index/etc that exists, and contains the SQL commands used to created the item in the first place. With a bit of fiddling, this can be used to reconstruct the .dump CLI functionality. So the output will be an array of strings, each a separate SQL command, and setAllState might be implemented with a simple db.exec(lines.join('\n')) (although maybe it wants to be a ss=createFromDump(lines) function instead).

[warner]

Actually, for our purposes, we probably don't even need the dumped data to be a string. SQLite has a "serialize" API, which better-sqlite3 exposes as blob = db.serialize(), which just returns the raw in-memory DB contents. The corresponding SQLite [unserialize](https://sqlite.org/c3ref/deserialize.html) API is exposed a constructor argument:

const buffer = db.serialize();
db.close();
db = new Database(buffer);

which we might then have swingstore expose as createFromSerialized(buffer), a sibling of initSwingStoreopenSwingStore.

That would be sufficient for the "clone a swingstore" requirements of the unit tests that use this.

[warner]

closing in favor of version that sits on top of #6781 and #6755