bug#53636: 29.0.50; face-remapping broken on master

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 30 Jan 2022 21:19:17 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 53636@debbugs.gnu.org, tsdh@gnu.org
> 
> > I'm not sure whether that's a bug or not?  (That remapping a parent face
> > has no effect.)
> 
> But it does have effect.  Try "C-x 5 b *scratch* RET" after evaluating
> the first face-remap-add-relative, and you will see that it does have
> effect.  So it's something more subtle...
> 
> And yes, I think the extra indirection we now have on master exposed a
> problem we never saw before.

Actually, I think this is a new problem on master, introduced by
making the mode-line face be a parent of mode-line-active and
mode-line-inactive faces.  When that was done, lookup_basic_face was
changed to use mode-line-active instead of mode-line, so now the
mode-line face is not recomputed when face-remapping-alist is changed.
Instead, we recompute mode-line-active and mode-line-inactive, but
those are not in face-remapping-alist in this scenario, so they don't
change on the existing frame.

Do we still need the mode-line as a parent of these two faces, or can
we go back to what we had before the variable-pitch mode-line changes?