ses: throw AggregateError for module load errors

[boneskull]

What is the Problem Being Solved?

Currently, if one or more modules failed to load (related: #2832 which adds a flag to disable error aggregation), ses throws aggregates the loading errors into a single TypeError.

Semantically, it would be more appropriate to throw an AggregateError.

Description of the Design

• We need to decide what to do with only a single module failed to load:
  • Should we throw an AggregateError with a single member?
  • Or should we re-throw the original error?
  • Or something else?
• Unless instructed otherwise, the AggregateError.errors prop will contain the original module-loading errors; aside from the first original module-loading error thrown in #2832, these objects are not currently exposed by ses. If we need to do something with them, I will need to know.
• Should we retain the same error message as is currently used in the TypeError, or can we use a message like "n module(s) failed to load; see errors for details"
• Fall back to TypeError if AggregateError is unsupported (or has incomplete support; see below).

Security Considerations

I expect AggregateError would already be tamed so that it would not leak information. If there are extra steps that need to be taken to throw this safely, I don't know what they are (see note about original errors in above).

Scaling Considerations

n/a

Test Plan

• If one module-loading error occurs, assert the exception behavior
• If multiple module-loading errors occur, assert the exception behavior
• Update and/or remove existing tests expecting the old TypeError and its honkin' message prop

Compatibility Considerations

Can I use AggregateError?

From this data, it appears major browsers have supported AggregateError since late 2020, so I think it's safe. It is present in Node.js v16+.

AggregateError is not serializable in Node.js; see https://github.com/whatwg/html/pull/5749. I have no idea if this matters. If it's a requirement, then this change I am proposing won't be feasible for at least several years.

Upgrade Considerations

This will break anyone wrapping ses who is depending on a TypeError. For that reason, I'd call it a breaking change.