This means that A<B<T, C<U>>> will include the keys for B and C now.

Fixes the secondary cause of #17716 — when comparing Bluebird<string> to Bluebird<string>, the compilation ends up using two versions of Bluebird. And it turns out Bluebird is a very large type, and nearly every method returns another instance of Bluebird. This causes the compiler to run out of memory and crash. With this fix, compilation finishes in 2.9 seconds compared to 0.9 seconds when package deduping work correctly, skipping the structural Bluebird <-> Bluebird comparison.

The fix works because many of Bluebird's methods return Bluebird<T[]>. So extending getTypeReferenceId to understand arrays allows caching to perform better. The intuition is that if we don't learn anything by relating A<T> ==> B<T> when already relating A<U> ==> B<U>, then we also don't learn anything by relating A<T[]> ==> B<T[]> when already relating A<U[]> ==> B<U[]>.

This technique, in fact, generalises to any depth of nested type references. that is a type argument of a type reference. So if we are already relating Foo<Bar<T, Baz<V>>> ==> Qux<Quid<T, Quam<V>>> then we will skip Foo<Bar<U, Baz<W>>> ==> Qux<Quid<U, Quam<W>>>.

This works by generating the same key in getTypeReferenceId. I add one additional case that checks if a type argument is itself a type reference with generic arguments. If so, then getTypeReferenceId calls itself recursively on that type argument.

Note that we could limit the depth of the expansion when generating the key by adding a depth parameter to getTypeReferenceId.