Note [No deferring for multiplicity errors]

As explained in Note [Coercion errors in tcSubMult] in GHC.Tc.Utils.Unify,
linear types do not support casts and any nontrivial coercion will raise
an error at the end of typechecking (a delayed error).

This means that even if we defer a multiplicity mismatch during typechecking,
the desugarer will refuse to compile anyway. Worse: the delayed error would
shadow the type mismatch warnings (#20083).  As a solution, we refuse to defer
submultiplicity constraints. Test: T20083.

To determine whether a constraint arose from a submultiplicity check, we
look at the CtOrigin. All calls to tcSubMult use origins which are not
used outside of linear types.

In the future, we should compile unsolved multiplicity constraints to a runtime error with
-fdefer-type-errors, but there's currently no good way to insert this type error
in the desugared  program. Especially in a way that would pass the linter.
This plan is tracked in #20083.