Don't attempt to report signature candidate errors on relation overflows

[Andarist]

This is tricky and I don't have a test case that could be committed to cover for this (I have one that times out on me locally unless I bump the timeout significantly and it would surely time out on CI).

It is possible for chooseOverload to run into an excessive complexity error when checking the argument's type against the parameter's type. But that doesn't guarantee the same error failure will happen when getSignatureApplicabilityError gets called again for error reporting purposes.

At this time, the relation caches might be "partially" warm already and the same-ish relation check might, this time, run under the limit and produce no error. This is, likely, especially true when dealing with object literals - given each checkObjectLiteral produces a new type identity (and thus that type itself won't reuse spoiled/failed entries from the relation cache).

This can lead to hitting an existing assert: "No error for last overload signature". It can be observed after:

• checking out d1633a1c44dd2423623bd52cad8224213ed5ebed
• running npx hereby runtests --tests="crossProductUnionIntersectionRepeatedPropDeclarationsNoOOM2" --no-lint --timeout 24000000 (it should complete way before the specified timeout but the chances it won't complete under default 40s are high)
• dropping 0a222aa53e03c20233fdd52d6e47e69517cad04a (that's the cherry-picked commit from this PR)
• re-running the above test command. This time it should hit the assert

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.