Features needed from Error + console + assert

[erights]

See Agoric/agoric-sdk#1619

First, need to move assert package from agoric-sdk to SES-shim.

Combine error taming, console taming + features, and assert into a new a group that shares some hidden state.

If we can break up the error taming into a minimal first error taming to be safe (which might be the current one) and once SES supports vetted shims, we might make this triple an enhanced error,console,assert shim that replaces the tamed error. That would let us cleanly move it into its own package, and to omit it from minimal SES configurations.

The agoric-sdk assert package currently logs the actual data from the details template literal to the console when the error is thrown. Rather, in a manner similar to how the error-repair uses a weakmap on the side to associate stack trace info with an error, assert could likewise do so with the data from the details template literal. It should delay rendering this diagnostic data until that error is sent back to the console.

Our enhanced console, when getting an error object, should render any stack trace it held on the side in that weakmap, emulating the current de-facto typical console behavior on untamed errors, while keeping the stack hidden to those that just have the error. The old Caja/SES error taming did this.

Likewise, when getting an error object, our enhanced console should render the full details info it had kept on the side, if any, which keeping that data hidden.

It would generally be good to ask the console to associate hidden info with an error, to be rendered to the console only when the error is rendered. This would require adding a new non-standard api, perhaps to our console object. With such a generally available api, the new assert package would not need a special arrangement.

This could be used to keep stack traces associated with passed errors. Errors are passed by copy between mutually suspicious machines. Therefore anything hidden cannot be sent. The answer (with echoes in Causeway) is that the marshal layer on the sending side logs the error that it is sending, together with an extra marshal-generated identifier that it also sends in the serialized error record. The marshal on the receiving side asks its own console to associate this identifier with the received error. Someone, or some tool, that is given access to both logs can stitch them together --- can find the sending-side stack trace log that it uses to diagnose the stackless error as received.

[erights]

See #324