Fix scoping of TyCon binders in TcTyClsDecls

This patch fixes #17566 by refactoring the way we decide the final
identity of the tyvars in the TyCons of a possibly-recursive nest
of type and class decls, possibly with associated types.

It's all laid out in
  Note [Swizzling the tyvars before generaliseTcTyCon]

Main changes:

* We have to generalise each decl (with its associated types)
  all at once: TcTyClsDecls.generaliseTyClDecl

* The main new work is done in TcTyClsDecls.swizzleTcTyConBndrs

* The mysterious TcHsSyn.zonkRecTyVarBndrs dies altogether

Other smaller things:

* A little refactoring, moving bindTyClTyVars from tcTyClDecl1
  to tcDataDefn, tcSynRhs, etc.  Clearer, reduces the number of
  parameters

* Reduce the amount of swizzling required.
  Specifically, bindExplicitTKBndrs_Q_Tv doesn't need
    to clone a new Name for the TyVarTv, and not
    cloning means that in the vasly common case,
    swizzleTyConBndrs is a no-op

  In detail:
    Rename newTyVarTyVar --> cloneTyVarTyVar
    Add newTyVarTyTyVar that doesn't clone
    Use the non-cloning newTyVarTyVar in
       bindExplicitTKBndrs_Q_Tv
       Rename newFlexiKindedTyVarTyVar
           --> cloneFlexiKindedTyVarTyVar

* Define new utility function and use it
     HsDecls.familyDeclName ::
        FamilyDecl (GhcPass p) -> IdP (GhcPass p)

Updates haddock submodule.

1 files changed, 0 insertions, 0 deletions

diff --git a/utils/haddock b/utils/haddock
-Subproject 4808003d2238f76aee96d22cc022cee3e049f6a
+Subproject f3e3c4a766805a1bbea75bf23b84fdaaf053c22