Strange over-liberal 'deriving' validity test

Currently GHC accepts an arbitrarily complicated IrredPred in the context of a derived instance. E.g. here is test deriving/should_compile/T14339

newtype Foo = Foo Int

class Bar a where
  bar :: a

instance (TypeError (Text "Boo")) => Bar Foo where
  bar = undefined

newtype Baz = Baz Foo
  deriving Bar

Currently we get the derived instance

instance TypeError (Text "Boo") => Bar Baz

But is that really what we want? It defers the type error. Surely we should use standalone deriving if that is really what we want?

More generally, GHC.Tc.Validity.validDerivPred has this code

validDerivPred tv_set pred
  | not (tyCoVarsOfType pred `subVarSet` tv_set)
  = False  -- Check (VD3)

  | otherwise
  = case classifyPredType pred of
       ClassPred cls tys -> ...

       IrredPred {}   -> True   <-------------- YIKES!

       EqPred {}      -> False  -- Reject equality constraints
       ForAllPred {}  -> False  -- Rejects quantified predicates

This accepts an abitrarily complicated predicate, provided it's an IrredPred like c blah blah.

@rae and I think this is a bug, and we should tighten up validDerivPred. I tripped over this in !7050 (merged), but I'm opening a ticket because fixing the bug could break some (obscure, probably wrong) programs.

@RyanGlScott maybe you'd like to look at this?