Refactor @wry/equality to support custom [deepEquals] methods

[benjamn]

The @wry/equality package currently uses only === equality to compare objects whose Object.prototype.toString tag is something other than [object Object], but it can mistakenly use deep equality for custom classes/objects that use the default [object Object] tag. This is a mistake because there's no guarantee iterating over the public enumerable properties of an arbitrary object is a good way to check for equality, so it's better to stay safe and use ===.

This PR fixes that mistake by comparing objects that have custom prototypes (other than Object.prototype or null) using only === by default. Since this restriction potentially leaves custom objects with no way to participate in deep equality checking, this PR allows objects to implement a [deepEquals] method if they want to participate, where deepEquals is a Symbol that must be imported from the @wry/equality package:

import {
  deepEquals,
  DeepEqualsHelper,
} from "@wry/equality"

class Point2D {
  constructor(
    public readonly x: number,
    public readonly y: number,
  ) {}

  [deepEquals](that: Point2D, equal: DeepEqualsHelper) {
    return this === that || (
      equal(this.x, that.x) &&
      equal(this.y, that.y)
    );
  }
}

This optional [deepEquals] method must be defined by both objects, and a[deepEquals](b) must agree with b[deepEquals](a) (if a[deepEquals] !== b[deepEquals]). If you need to perform nested comparisons, you should use the predicate function passed as the second parameter (equal in the Point2D example above), since it knows which objects have been compared previously, so cycles in the graph will not cause infinite loops.

In the process of supporting [deepEquals], I realized the big switch (aTag) {...} list within @wry/equality had gotten long enough to be slower than using a Map to look up checker functions (which should take constant time, regardless of how many types are supported by @wry/equality), so I refactored that system to use a Map instead of a switch.

[benjamn]

For better or worse, since equality checking now potentially calls into user-provided deepEquals methods, we cannot be sure the check(a, b) function will return before other code calls equal(...), so the trick of using a single previousComparisons map and clearing it after each check no longer works, and we need to allocate a separate DeepChecker (with its own comparisons map) for each call to equal(a, b).