review or replace object-inspect.js used by xsnap console

[warner]

What is the Problem Being Solved?

In #4364, we changed the xsnap console renderer. Previously, it used the assert.quote function from SES, which grounds out in bestEffortStringify(), which is basically a JSON encoder with a replacer that handles non-JSON things like undefined. After #4364, it used a vendored copy of object-inspect.js (taken from the NPM object-inspect package), which should be pretty close to what Node.js uses for its own console global.

During the resulting discussion (Agoric folks can look at #eng_ses_internal on 08-feb-2022), @erights and @dckc expressed concern about object-internal.js. We didn't come to a consensus before we had to move on, but I think our general opinion was that we must either do a line-by-line review of object-internal.js, or write our own version of it (and use that version to replace assert.quote, making it more readable in the process).

The concerns are:

• object-internal.js runs in the start compartment as a vetted shim, so obviously has a lot of power
• the behavior must be a deterministic function of the inputs to a single console.* call
  • there must be no information or determinism leakage between multiple calls
    • (the implementation needs a WeakSet to tolerate cycles, but this should be scoped to a single call)
  • callers will receive a hardened console object and will not have access to a clock or weakrefs
  • however callers might supply a Proxy, or objects with getters, in an attempt to confuse the console
• the console should bottom out in a function that delivers one string per console.log() invocation
  • we might route these strings to the kernel process for inclusion in debug logs, and/or write them to stdout/stderr, and/or drop them
  • the renderer's behavior and metering should not depend upon what happens after it emits the string
  • it must emit strings even if the caller attempts to trick it with Proxies or getters
• the inputs to console.* might not be hardened, and console.* must not harden them

Description of the Design

Security Considerations

Test Plan

[dckc]

As noted in #4767 , @michaelfig and I have been using #2146 for this. A little redundancy doesn't hurt, I suppose. This is probably more clear. In particular, I neglected to add a comment to #2146 telling the story above.