Use per-dependants-set WeakMap-based cache

[aduth]

Related: WordPress/gutenberg#4955 (comment)
Related: Automattic/wp-calypso#20330
Related: Automattic/wp-calypso#19771
Related: Automattic/wp-calypso#20547

This pull request seeks to provide improved caching for "per-key" selectors, taking advantage of WeakMap's behavior to automatically manage cache cleanup via garbage collection of unreferenced objects. This is heavily influenced by the implementation of Calypso's tree-select module.

More information is included in the docblock of the newly-introduced getCache function, responsible for returning a cache specific to each dependants set when possible:

Returns the cache for a given dependants array. When possible, a WeakMap
will be used to create a unique cache for each set of dependants. This
is feasible due to the nature of WeakMap in allowing garbage collection
to occur on entries where the key object is no longer referenced. Since
WeakMap requires the key to be an object, this is only possible when the
dependant is object-like. The root cache is created as a hierarchy where
each top-level key is the first entry in a dependants set, the value a
WeakMap where each key is the next dependant, and so on. This continues
so long as the dependants are object-like. If no dependants are object-
like, then the cache is shared across all invocations.

Testing instructions:

Verify that unit tests pass:

npm test

Verify that I'm not totally off-base with this implementation 😆

cc @samouri, @dmsnell, @youknowriad

[youknowriad]

Do you think the maxSize option still makes sense with this change? I think it reflects the maxSize per dependency set, so I guess it's not that useful anymore?

Otherwise, this looks good to me.

[aduth]

Do you think the maxSize option still makes sense with this change? I think it reflects the maxSize per dependency set, so I guess it's not that useful anymore?

Good call. I've never found myself caring to use this option, and it seems like it'd be difficult to implement with this new approach, so I've dropped it for now.

In e8c5cc2, I made the WeakMap support optional, which also helped simplify how to handle case where dependants include a primitive type. Only in environments where WeakMap is supported or the dependants include a primitive type do we need to perform shallow equality on the last dependants, as otherwise we don't ever need to clear the cache (relying on garbage collection when no references to original objects).

I'm considering both of the above revisions non-breaking, since WeakMap is an optional enhancement, and the options argument is simply ignored.