Fix #14579 by defining tyConAppNeedsKindSig, and using it

GeneralizedNewtypeDeriving and DerivingVia often generate code with excessive amounts of kind signatures, which is a bit unfortunate. Thankfully, there's a separate part of GHC that has already tackled the problem of calculating exactly when generated code needs explicit kind signatures (and when they don't)—the reify_tc_app function from TcSplice. reify_tc_app uses a heuristic defined in terms of the injective_vars_of_binder function, which works quite well in practice. (In fact, Haddock uses the same heuristic, which is why this patch updates the Haddock submodule— more on this in a bit.)

This exact same heuristic could be used to lop off some redundant kind signatures from the generated code in GND/DerivingVia, so this patch does exactly that. Specifically:

1. I define a tyConAppNeedsKindSig function in TyCoRep which implements the heuristic previously inlined into reify_tc_app. I explain how this heuristic works in Note [When does a tycon application need an explicit kind signature?] in TyCoRep (which was previously Note [Kind annotations on TyConApps] in TcSplice).

   We now use tyConAppNeedsKindSig in GND/DerivingVia–generated code to determine if generated tycon applications require explicit kind signatures or not. (I also use this function in Haddock, which is why the submodule is bumped.)

2. I extend injective_vars_of_binder with a Bool argument which controls whether specified arguments contribute towards injective positions or not (see Note [When does a tycon application need an explicit kind signature?] for an explanation of what "injective position" means). Note that if one religiously uses visible kind applications, this is true! Correspondingly, I change GND/DerivingVia to generate code that always instantiates specified arguments with visible kind applications.