Adds a (currently very conservative, based on design meeting feedback) limit on how large of a tuple type we will create through spread normalization.

On each recursion, checking T['length'] kicks off resolveObjectTypeMembers, which instantiates base types. Recall that an N-tuple is modeled something like

interface Tuple<T0, T1, ..., TN> extends Array<T0 | T1 | ... | TN> {
  0: T0;
  1: T1;
  // ...
}

So in order to instantiate the base type, we have to pass along an array type mapper mapping T0...TN to the “type arguments,” or the element types of this particular tuple. So even though, in this case, every element type is any, the source side of the mapper is an N+1-length array filled with N unique type parameter identities (plus the this type parameter). When we instantiate each union constituent T0 | T1 | ... | TN, we have to search through that N-length array of sources, even though in this case we’ll always find any in the target side.

So you can imagine by the time we get to the 15th recursion or so, this is starting to take a while, and we’re creating quite a lot of type parameter identities. Pretty much all the time was being spent in this spiral of trying to instantiate the Array base type.

Fixes #41771