Revamp the treatment of auxiliary bindings for derived instances

This started as a simple fix for #18321 (closed) that organically grew into a much more sweeping refactor of how auxiliary bindings for derived instances are handled. I have rewritten Note [Auxiliary binders] in GHC.Tc.Deriv.Generate to explain all of the moving parts, but the highlights are:

• Previously, the OccName of each auxiliary binding would be given a suffix containing a hash of its package name, module name, and parent data type to avoid name clashes. This was needlessly complicated, so we take the more direct approach of generating Exact RdrNames for each auxiliary binding with the same OccName, but using an underlying System Name with a fresh Unique for each binding. Unlike hashes, allocating new Uniques does not require any cleverness and avoid name clashes all the same...
• ...speaking of which, in order to convince the renamer that multiple auxiliary bindings with the same OccName (but different Uniques) are kosher, we now use rnLocalValBindsLHS instead of rnTopBindsLHS to rename auxiliary bindings. Again, see Note [Auxiliary binders] for the full story.
• I have removed the DerivHsBind constructor for DerivStuff—which was only used for Data.Data-related auxiliary bindings—and refactored gen_Data_binds to use DerivAuxBind instead. This brings the treatment of Data.Data-related auxiliary bindings in line with every other form of auxiliary binding.

Fixes #18321 (closed).