Pull out TypeError deeply when computing insoluble constraints

Ticket: #26400 (closed).

This MR cleans up all the code responsible for detecting whether a type contains "TypeError msg" applications nested inside it. All the logic is now in 'userTypeError_maybe', which is always deep. Whether it looks inside type family applications is determined by the passed-in boolean flag:

• When deciding whether a constraint is definitely insoluble, don't look inside type family applications, as they may still reduce – in which case the TypeError could disappear.
• When reporting unsolved constraints, look inside type family applications: they had the chance to reduce but didn't, and the custom type error might contain valuable information.

This MR also improves the detection of custom type errors, for example in equality constraints:

  TypeError blah ~# rhs

It used to be the case that we didn't detect the TypeError on the LHS, because we didn't look at equality constraints. Fixing this oversight improves detection of redundant pattern match warnings, fixing #26400 (closed).

TODO:

• Add T26400 test.
• Add test for weird cases like C alpha (TypeError msg), c alpha (TypeError msg) and TypeError msg ~ F alpha.
• Explain the subtle logic in a Note.