Demand: Let `Boxed` win in `lubBoxity` (#21119)

Previously, we let Unboxed win in lubBoxity, which is unsoundly optimistic in terms ob Boxity analysis. "Unsoundly" in the sense that we sometimes unbox parameters that we better shouldn't unbox. Examples are #18907 (closed) and T19871.absent.

Until now, we thought that this hack pulled its weight becuase it worked around some shortcomings of the phase separation between Boxity analysis and CPR analysis. But it is a gross hack which caused regressions itself that needed all kinds of fixes and workarounds. See for example #20767 (closed). It became impossible to work with in !7599 (merged), so I want to remove it.

For example, at the moment, lubDmd B dmd will not unbox dmd, but lubDmd A dmd will. Given that B is supposed to be the bottom element of the lattice, it's hardly justifiable to get a better demand when lubbing with A.

The consequence of letting Boxed win in lubBoxity is that we would regress #2387 (closed), #16040 (closed) and parts of #5075 (closed) and T19871.sumIO, until Boxity and CPR are able to communicate better. Fortunately, that is not the case since I could tweak the other source of optimism in Boxity analysis that is described in Note [Unboxed demand on function bodies returning small products] so that we recursively assume unboxed demands on function bodies returning small products. See the updated Note.

Note [Boxity for bottoming functions] describes why we need bottoming functions to have signatures that say that they deeply unbox their arguments. In doing so, I had to tweak wantToUnboxArg so that it will never unbox recursive data constructors. This is in line with our handling of them in CPR. I updated Note [Which types are unboxed?] to reflect that.

In turn we fix #21119 (closed), #20767 (closed), #18907 (closed), T19871.absent and get a much simpler implementation (at least to think about). We can also drop the very ad-hoc definition of deferAfterPreciseException and its Note in favor of the simple, intuitive definition we used to have.