initial thoughts

@DerekNonGeneric I'm not sure what exactly you're looking for, but here's this:

- `operator` is probably far too limiting to be of use past trivial comparisons such as `===`, `>`, `!==`, etc. Other comparisons such as regex matches, deep object equivalence, deep property comparisons or compound assertions won't have much use for it.
- Many of the mentioned properties in the ecosystem's `AssertionError` implementations are framework-specific. It's clear from the proposal that this is understood, but bears repeating.
- IMO _contextual information about the difference_ between `actual` and `expected` is absolutely necessary for any framework to make use of an `AssertionError`. I believe this was the intent behind `operator`, but again, I think that's insufficient. For example, we could be checking that object `foo` and object `bar` are not strictly equal. `operator` may be sufficient for this case, but without anything else, it cannot be expressed by just `actual` and `expected`--these properties may be useless at best and misdirection at worst. So it's the responsibility of whatever is throwing the `AssertionError` to put enough information in there that the consumer (a test framework perhaps) can display a representation. For that reason, a free-form `difference` property makes sense to me. This could be structured data or just a string; it will probably be difficult if not impossible to define/standardize a structure which would represent any "assertion" which can fail. At any rate--_something_ else is needed.
- In the case of "compound" assertions (e.g., array `foo` contains object `bar` _and_ has `length` `4`), an assertion library may make _both_ of these checks; if the first fails, it may not short-circuit the assertion. These failures would be combined into a single `AssertionError` then thrown. Is it possible to leverage the newish `cause` prop here, though it looks more like a linked list than "(potentially) multiple causes", so maybe not applicable?

("assertion libraries" above also means "assertion subsystems of testing frameworks")