fix(zoe): add zoe.installBundleID

[warner]

fix(zoe): add zoe.installBundleID

To transition Zoe from full contract bundles to bundlecaps, this adds a new
install API. E(zoe).install(bundle) is unchanged, but the new preferred
approach is E(zoe).installBundleID(bundleID). This requires the
corresponding bundle to be installed with the swingset kernel's
vatAdminService, either before or after installBundleID() (zoe will wait
forever for the bundle to be installed).

Zoe Installation objects retain their getBundle() method to accomodate
dapp tests that have not switched to the new approach, but it throws an error
if used on a new bundleID-based installation. A new method named
E(zoe).getBundleIDFromInstallation(allegedInstallation) can be used to both
validate the installation and get back the bundleID, but it throws on the old
bundle-based installations.

Internally, the installationStorage.unwrapInstallation now returns either
{ bundle, installation } or { bundlecap, bundleID, installation }. ZCF's
evaluateContract() method accepts either a bundlecap or a full bundle.

closes #4563

[warner]

This changes a handful of Zoe tests (to confirm that the new behavior works). It does not yet change the rest of the zoe tests, nor the tests elsewhere in agoric-sdk, nor the tests in dapps that live outside agoric-sdk. I need to change all of those before I can remove the old E(zoe).install API.

I also made a small swingset change to export a few types that are now part of the Zoe API (BundleID and a module type). This seems necessary to let packages/vats/ pass typechecking.

[erights]

Why *Bundlecap instead of *BundleCap? Since none of this has been merged yet, if we're going to rename it, now is the ideal time.

[turadg]

non-blocking but FYI, we can use unions to convey mutual exclusion. It has the advantage over optionals of guaranteeing to consumer that one of them is defined. E.g.,

type BundleOrBundleCap = {bundle: SourceBundle} | {bundleCap: BundleCap, bundleId: BundleID};

or in jsdoc,

/** @typedef  { {bundle: SourceBundle} | {bundleCap: BundleCap: bundleId} } BundleOrBundleCap */

then intersection for the return type

Promise<BundleOrBundleCap & {installation: Installation}>

[warner]

aye, thanks, will look into that later, there's another BundleOrBundleCap floating around which doesn't include the bundleID that I don't want to collide with

[turadg]

collide with

Want to point out that the possibility of collisions is due to ambient types. Because TypeScript is structurally typed, there's usually little problem with redundant definitions. (Besides code maintenance/documentation.)