Backpack instantiations need to be typechecked to make sure that the
arguments fit the parameters. `tcRnInstantiateSignature` checks
instantiations with concrete modules, while `tcRnCheckUnitId` checks
instantiations with free holes (signatures in the current modules).

Before this change, it worked that `tcRnInstantiateSignature` was called
after typechecking the argument module, see `HscMain.hsc_typecheck`,
while `tcRnCheckUnitId` was called in `unsweep'` where-bound in
`GhcMake.upsweep`. `tcRnCheckUnitId` was called once per each
instantiation once all the argument sigs were processed. This was done
with simple "to do" and "already done" accumulators in the fold.
`parUpsweep` did not implement the change.

With this change, `tcRnCheckUnitId` instead is associated with its own
node in the `ModuleGraph`. Nodes are now:
```haskell
data WorkGraphNode
  = InstantiationNode IndefUnitId
  | ModuleNode ModSummary
```
instead of just `ModSummary`; the `InstantiationNode` case is the
instantiation of a unit to be checked. The dependencies of such nodes
are the same free holes as was checked with the accumulator before. Both
upsweeps on such a node call `tcRnCheckUnitId`.

The instantiation nodes are not depended on by other nodes; `tcRnCheckUnitId` is
just being called for errors. I do take this as evidence for the argument that
perhaps my patch is over-engineered; one could also just leave the graph as-is
and post upsweep `tcRnCheckUnitId` all unit-ids unconditionally. Now, if there
is extra `-j` sooner one can get the errors quicker than that with mine, but
without the dependencies into the merged node (mimicking the eagerness of the
fold of the sequential upsweep) this isn't guaranteed to happen.

I admit I went with the current approach before I realized that nothing
else depended on the effects for `tcRnCheckUnitId`, but I still think
it is the right one with future changes in mind. For this, I refer to
"Note [Identity versus semantic module]". The current reasoning appeals
to the compilation pipeline invariants, but if we get multi package
support [proposal 23], we could have all three of the original
signature, argument, and instiation in home packages. I think having
separate dependency nodes for each of those 3 might yield more
incrementality and/or parallelism, especially if nodes became per
pipeline stage.

Fixes #17188

Things yet to do:

* [ ]  There are extra numbered steps that don't print out, probably should have some `[m of n] checking instantiation ...`

* [ ]  Errors are rendered slightly differently for some reason

[proposal 23]: https://github.com/ghc-proposals/ghc-proposals/pull/263