type to a `RealSrcLoc` to accomodate backpack

We don't want to print out data from the interface file (#20489)

  Tickets #20469 and #20470 showed that the current
  implementation of arrows is not at all up to the task
  of supporting GADTs: GHC produces ill-scoped Core programs
  because it doesn't propagate the evidence introduced by a GADT
  pattern match.

  For the time being, we reject GADT pattern matches in arrow notation.
  Hopefully we are able to add proper support for GADTs in arrows
  in the future.

Like the built-in type defaulting rules these plugins can propose candidates
to resolve ambiguous type variables.

Machine learning and other large APIs like those for game engines introduce
new numeric types and other complex typed APIs. The built-in defaulting
mechanism isn't powerful enough to resolve ambiguous types in these cases forcing
users to specify minutia that they might not even know how to do. There is
an example defaulting plugin linked in the documentation. Applications include
defaulting the device a computation executes on, if a gradient should be
computed for a tensor, or the size of a tensor.

See https://github.com/ghc-proposals/ghc-proposals/pull/396 for details.

It's important that when -finfo-table-map is enabled that we generate
IPE entries just for those info tables which are actually used. To this
end, the info tables which are used are collected just before code
generation starts and entries only created for those tables.

Not accounted for in this scheme was the dead code elimination in the
native code generator. When compiling GHC this optimisation removed an
info table which had an IPE entry which resulting in the following kind
of linker error:

```
/home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sS_info'
/home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sH_info'
/home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sm_info'
collect2: error: ld returned 1 exit status
`cc' failed in phase `Linker'. (Exit code: 1)
Development.Shake.cmd, system command failed
```

Unfortunately, by the time this optimisation happens the structure of
the CmmInfoTable has been lost, we only have the generated code for the
info table to play with so we can no longer just collect all the used
info tables and generate the IPE map.

This leaves us with two options:

1. Return a list of the names of the discarded info tables and then
   remove them from the map. This is awkward because we need to do code
   generation for the map as well.
2. Just disable this small code size optimisation when -finfo-table-map
   is enabled. The option produces very big object files anyway.

Option 2 is much easier to implement and means we don't have to thread
information around awkwardly. It's at the cost of slightly larger object
files (as dead code is not eliminated).

Disabling this optimisation allows an IPE build of GHC to complete
successfully.

Fixes #20428

Closes #20013

The tests Capi_Ctype_001 Capi_Ctype_002 T12010 pass regularly on CI so
let's mark them unbroken and hopefully then we can fix #20013.

The current code assumes the non-moving generation is always
generation 1, but this isn't the case if the amount of generations
is greater than 2

Fixes #20461