Diagnostic codes

This MR continues Richard's work on adding error codes to GHC (#21684 (closed)).

Here are some of the changes relative to that work:

1. All the error code logic happens in the single module GHC.Tc.Error.Codes.
2. DiagnosticCode now holds a string (for the prefix) and a number (the actual code), instead of two SDocs. This means that tooling can inspect a DiagnosticCode, which wasn't possible when both fields were SDocs.
3. Removed the separate lists of used/deprecated diagnostic codes. This is no longer necessary now that all error codes are defined in a single location (GHC.Tc.Error.Codes). This saves contributors from having to include the error in two different locations in the compiler.
4. Replaced the test for uniqueness of error codes by the usage of an injective type family. This means that users get immediate feedback (if using HLS) as opposed to having to find out about a problem potentially much later on (e.g. when CI runs).
5. Instead of implementing the error code as a function, we use Generics to retrieve the constructor name and get the associated error message. There is a separate type family which specifies for which constructors we don't immediately want to give an error code, and instead want to recur into an argument.
6. Custom type errors are thrown when a contributor forgets to add a diagnostic code which explains how to go about it (usually a one line change, adding a type family equation for that constructor, unless the want to split up the constructor into several different error codes).
7. Removed the gen-error-codes tool: I think it's simpler for new contributors to simply generate random codes on their own (e.g. using random.org) as opposed to having to use a separate tool. Clashes are unlikely, and caught early with the use of an injective type family.

I've also refactored the TcSolverReport datatype and related, improving how constraint solver errors are reported (see #20772).