feat(cosmic-swingset): use a fake chain for scenario3

[michaelfig]

This introduces block latency so that the scenario3 chain
behaves much more like a real blockchain, but within the
same process (for debuggability) and without the
actual Cosmos SDK usage.

Closes #321

[warner]

Looks like this needs to be rebased onto current trunk: the vat-timerWrapper.js change has already landed. If there are remaining SwingSet changes to make, let's put them into their own commit, separate from the cosmic-swingset changes.

[michaelfig]

Looks like this needs to be rebased onto current trunk: the vat-timerWrapper.js change has already landed.

Done.

If there are remaining SwingSet changes to make, let's put them into their own commit, separate from the cosmic-swingset changes.

@warner, Do you mean "into their own PR"? If so, I've now reverted the SwingSet changes and can create an issue and PR for the other (minor) SwingSet change.

[warner]

@michaelfig and I walked through this today.. I think it's ok to land. I'm a little worried about the technical debt incurred by layering this on top of the existing scenario3, but the functionality is compelling, and we're planning to refactor all of this soon in the agoric-cli package.

Before this change, "scenario 2" meant two processes. The first used cosmos-sdk and a swingset embedded in the chain that held the "central-services" vats. The second used ag-solo with a swingset that held the "client-side" vats and speaks http to the frontend. "scenario 3" meant one process (with one swingset, holding both central-services and client-side vats, speaking http to the frontend, and no cosmos-sdk or golang anywhere).

With this change, "scenario3" means one process with two embedded swingset kernels (one for central-services, one for client-side), which communicate to each other through a mailbox (on a delay).

Let's put a note to that effect in the Makefile to remind us how this works/worked.

Another thought we had was to retain at least the notes about how start what used to be scenario3. It's not worth creating a "scenario4" to hold it, but let's cut-and-paste-and-comment-out the scenario3 rules for the benefit of teaching us something in the future.

Finally, maybe consider removing the empty scenario3-run-chain target, and renaming the remaining one something like scenario3-run. We only have one process, so we only need one run command, and I think the false parallelism with the two-process scenario1/2 cases isn't super helpful. Or maybe it just interferes with my tab-completion (when I type make sc TAB 3-ru TAB, I get stuck with make scenario3-run-c instead of completing all the way to the one useful value: make scenario3-run-client)