Error on complex array literals

[ahejlsberg]

Large array literals containing object literals that all have distinct types (e.g. because each has a unique property name) end up producing union types with exponentially increasing complexity, due to subtype reduction and object literal normalization (#19513). Rather than "hanging" the type checker by consuming inordinate amounts of memory and time, we now issue an error when an array literal is deemed too complex. The metric we use is 500,000 or more failed subtype checks, which for example would be caused by an array literal containing 1000 or more object literals with distinct types.

const a = [
  { text: "zero", value: 0, "zero": 0 },
  { text: "one", value: 1, "one": 1 },
  { text: "two", value: 2, "two": 2 },
  // ... thousands more
];

The "Array literal type is too complex to represent" error we now report is easily squelched using a type assertion on the first element:

const a = [
  { text: "zero", value: 0, "zero": 0 } as any,
  { text: "one", value: 1, "one": 1 },
  { text: "two", value: 2, "two": 2 },
  // ... thousands more
];

This causes the array literal to have the inferred type any[].

Fixes #28540.

[RyanCavanaugh]

Needs merge conflict resolution

[weswigham]

@RyanCavanaugh probably worth mentioning that #28727 fixes the same original bug with a smaller fallout of disabling-things-which-really-should-work. (it's not linked in this PR, but is mentioned in the bug this PR fixes)

[ahejlsberg]

Closing in favor of #29435.