bug#47291: bug#51404: Support system dark mode on Windows 10

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Vince Salvino <salvino@coderedcorp.com>,  51404@debbugs.gnu.org,
>  47291@debbugs.gnu.org
> Date: Thu, 11 Nov 2021 06:36:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure I understand why 'light' necessarily means the old
> > behavior: we didn't set any theme before this change, we just used the
> > Windows default.  So maybe there should be 4 values:
> >
> >   nil: never follow the system theme (use Windows default)
> >   t: always follow the system theme
> >   light: force light theme (currently the same as nil)
> >   dark: force dark theme.
> 
> For a similar bug report, see bug#47291.  And we really should support
> this on GNU/Linux, too, so having three different methods to support
> this seems sub-optimal.

I'm not sure unification is possible here, because the functionality
is quite different, AFAICT.  At least for the functionality in this
bug report, we cannot apply the system theme to an existing frame, we
can only apply it at frame creation time.  So having a handler for
such changes will be able to affect only the frames created after the
change.  Or at least that is my understanding; the code definitely
applies the dark/light theme as part of creating a frame.

Also, having a dynamic thing that tracks changes in these settings
would on Windows mean listening and processing a special window-system
message, which seems to be WM_THEMECHANGED or maybe WM_SETTINGCHANGE.
But that's not what the code installed in this bug report does.

So the functionality seems similar, but the details differ.