validDerivPred: Reject non-well-formed constraints in IrredPreds

This brings the IrredPred case in sync with the treatment of ClassPreds as described in Note [Valid 'deriving' predicate] in GHC.Tc.Validity. Namely, we should reject IrredPreds that are inferred from deriving clauses whose arguments contain other type constructors, as described in (VD2) of that Note. This has the nice property that deriving clauses whose inferred instance context mention TypeError will now emit the type error in the resulting error message, which better matches existing intuitions about how TypeError should work.

While I was in town, I noticed that much of Note [Valid 'deriving' predicate] was duplicated in a separate Note [Exotic derived instance contexts] in GHC.Tc.Deriv.Infer. I decided to fold the latter Note into the former so that there is a single authority on describing the conditions under which an inferred deriving constraint can be considered valid.

This changes the behavior of deriving in a way that existing code might break, so I have made a mention of this in the GHC User's Guide. It seems very, very unlikely that much code is relying on this strange behavior, however, and even if it is, there is a clear migration path using StandaloneDeriving.

Fixes #22696 (closed).