Draft: Re-organize tcApp to facilitate eta-expansion work

This patch shuffles around some of the operations taking place in tcApp.

The justification comes from work on improving how we eta-expand data constructors (e.g. !8027 (closed)).

The current approach to typechecking/desugaring data constructors is explained in Note [Typechecking data constructors]. !8027 (closed) shows that it would make more sense to only eta-expand when we need to, which dovetails nicely with the eta-expanion check done by hasFixedRuntimeRep_remainingValArgs in tcApp.

To accomodate such a refactor, we want hasFixedRuntimeRep_remainingValArgs to work with typechecked arguments, returning new typechecked arguments and a new app_res_rho in which linear arrows have been given new multiplicities, instead of doing so in tcInferDataCon. To facilitate this, this patch moves around the order of operations in tcApp.

I'm waiting to see what CI says about the impact on error messages. There used to be a note

Note [Unify with expected type before typechecking arguments]

which justified why we unified the result type before typechecking arguments, but I didn't find the example given in the Note to be compelling. In my opinion the error message is just as good when doing things in the other order. But perhaps it is a genuine regression in other situations; we'll see what CI says.