feat(ses): Carry compartment names in error messages

[kriskowal]

This change adds the name option to the Compartment constructor, a name accessor to the Compartment prototype, and annotates certain errors that pass through the Compartment with the name of the compartment they pass through.

[erights]

From reading this description I was confused about what to expect.

• These are only errors that happen during load. What about errors raised by user code during module initialization?
• By "annotated" you do not mean that you mutate the error object in place. (Whew!) Rather you rethrow a new error object that is like the old one except for added text in the message string.

[erights]

Maybe <unnamed>?

[erights]

Given

https://github.com/Agoric/SES-shim/blob/cbe689e018b2786076d18c1883d75b00eb051fb4/packages/ses/src/tame-error-constructor.js#L9-L17

we should reproduce the error class as well

Suggested change

	throw new Error(
	const ErrorConstructor = NativeErrors[error.name] || Error;
	throw new ErrorConstructor(

Rather than importing NativeErrors from tame-error-constructor.js, it should go in whitelist.js. But that does not need to happen in this PR.

[erights]

Given the recursion, is the intent that each level of recursion adds its own location info?

[erights]

The problem with reconstructing the error object is that you silently lose the call stack associated with the original error object. What assumptions are you making about ambient availability of a console object for this code? Nothing I've done for keeping track of error stack correspondence is close to ready. One thing this code can do in the meantime is to do something like

    const newError = NewErrorContructor(...);
    if (someAppropriateOption) {
      console.log(error, 'rethrown as', newError);
    }
    throw newError;

The normal console behavior is to emit the stacks associated with error objects it logs. This would at least give us the correspondences to grovel through to find the original error stack.

[erights]

Depending on your goals and your console assumptions, we could take the opposite approach:

    if (someAppropriateOption) {
      console.log(error, `, loading  ${q(moduleSpecifier)} in compartment ${q(name,)}`);
    }
    throw error;

This completely avoids recreating new error objects as well as modifying the thrown one in place. It rethrows the one we've got, which retains the stack trace it was constructed with. All the new compartment-name diagnostic info in only logged to the console.

[kriskowal]

Would it suffice to reüse the error.constructor?