Introduce Concrete# for representation polymorphism checks

This MR replaces the previous MR !6164 (closed), which was becoming too large.

This patch moves the representation polymorphism checks from the desugarer to the typechecker, by introducing a magic Concrete# predicate, and emitting Concrete# Wanted constraints to rule out representation polymorphism where it isn't allowed. A broad outline in laid out in the wiki page FixedRuntimeRep.

This only implements PHASE 1 of the plan outlined on the wiki page: we don't allow Concrete# constraints to be rewritten (only zonked), so this doesn't add support for type families in RuntimeReps.

Fixes these tickets:

• #17907 (closed)
• #20277 (closed)
• #20330 (closed)
• #20423 (closed)
• #20426 (closed)

Unresolved issues:

• Clarify the notions of representation-polymorphic and levity-polymorphic in all the notes that talk about these.
• Do we keep the boxed typeclass constaint Concrete, when it is only used for Backpack? I've removed it, as further thought seemed to indicate that it does make good sense for AbstractTyCons to always be considered concrete; not doing so makes it difficult to implement Core Lint correctly.
• Re-use inert_irreds instead of adding a new field inert_specials to the inert set.
• Provide a water-tight argument to ensure that, even in PHASE 2, any implementation of an abstract TyCon in a signature file is indeed concrete.
• Check that Ed Kmett's unboxed package can indeed compile. We have RepPolyBackpack2.bkp in the test-suite that does something very similar, so in theory I'm rather confident we'll be OK, but I've had issues actually compiling Ed's package.