Note [Unrealised opportunity in plusDmd]

Recall the lazification of SubDemands happening in `plusDmd` as described in
Note [SubDemand denotes at least one evaluation].

We *could* do better when both Demands are lazy already. Example
  (fun 1, fun 2)
Both args put Demand SC(S,L) on `fun`. The lazy pair arg context lazifies
this to LC(S,L), and it would be reasonable to report this Demand on `fun` for
the entire pair expression; after all, `fun` is called whenever it is evaluated.
But our definition of `plusDmd` will compute
  LC(S,L) + LC(S,L) = (L+L)(M*C(S,L) + M*C(S,L)) = L(C(L,L)) = L
Which is clearly less precise.
Doing better here could mean to `lub` when both demands are lazy, e.g.,
  LC(S,L) + LC(S,L) = (L+L)(C(S,L) ⊔ C(S,L)) = L(C(S,L))
Indeed that's what we did at one point between 9.4 and 9.6 after !7599, but it
means that we need a function `lubPlusSubDmd` that lubs on lower bounds but
plus'es upper bounds, implying maintenance challenges and complicated
explanations.

Plus, NoFib says that this special case doesn't bring all that much
(geom. mean +0.0% counted instructions), so we don't bother anymore.