Note [Why Boxity in SubDemand and not in Demand?]

In #19871, we started out by storing 'Boxity' in 'SubDemand', in the 'Prod'
constructor only. But then we found that we weren't able to express the unboxing
'seqSubDmd', because that one really is a `Poly C_00` sub-demand.
We then tried to store the Boxity in 'Demand' instead, for these reasons:

  1. The whole boxity-of-seq business comes to a satisfying conclusion
  2. Putting Boxity in the SubDemand is weird to begin with, because it
     describes the box and not its fields, just as the evaluation cardinality
     of a Demand describes how often the box is used. It makes more sense that
     Card and Boxity travel together. Also the alternative would have been to
     store Boxity with Poly, which is even weirder and more redundant.

But then we regressed in T7837 (grep #19871 for boring specifics), which needed
to transfer an ambient unboxed *demand* on a dictionary selector to its argument
dictionary, via a 'Call' sub-demand `C(1,sd)`, as
Note [Demand transformer for a dictionary selector] explains. Annoyingly,
the boxity info has to be stored in the *sub-demand* `sd`! There's no demand
to store the boxity in. So we bit the bullet and now we store Boxity in
'SubDemand', both in 'Prod' *and* 'Poly'. See also Note [Boxity in Poly].