feat: introduce property for appearance but for now only dark is supported

[benoitf]

What does this PR do?

add a new setting which is hidden to toggle between light or dark mode
it's hidden because if the user is asking for light mode it will be still displayed with dark colours.

It's set to system mode but even if all the logic is there, at the end we force 'dark' mode for the system mode to not break users having wrong display of items until the light mode is completed

But it toggles on or off the dark theme support then we can use dark: prefix in the codebase to make the style being specific for the dark theme

it's like the beginning of more upcoming PRs

Screenshot/screencast of this PR

N/A as setting is hidden

What issues does this PR fix or reference?

related to #576

How to test this PR?

you can replace hidden: true by hidden:false and then you'll see the preference in preferences page

default is system so it means it'll use mode of the underlying operating system
(but default will still be mapped now to dark to not let display something broken to the user as it's the default property)

then you can inspect with 'light' or 'dark' toggle the class of the html root element (it should add dark or remove dark if you change the property)

unit tests have been added

[lstocchi]

So from now on, we should go and update all bg/text color classes with dark: .... and the default value will be used in light mode?

[benoitf]

@lstocchi yes that is the plan unless using a radical different approach like https://github.com/L-Blondy/tw-colors but it won't work for what we have now as we're not using 'primary' color but a color from a palette

[deboer-tim]

I had a very similar change that I was starting to test, and I'm not ashamed to say this is more thorough and sets us up well for opening the preference later. :)

My only concern is that I think we should also set the default color scheme in addition to the class, i.e.:
html.style.setProperty('color-scheme','light');
and
html.style.setProperty('color-scheme','dark');
in Appearance.svelte.

This would set the default scheme so that we only need to override where we don't match, instead of having to set styles for everything. If we do this then it's also a fix for #4888 (and we can close that part of #4826). If not, then we need to create our own dark scrollbar styling and always do things like "text-black dark:text-white" even though that would be the default.

Approving since this is an extra step beyond and I agree with what's here.

[deboer-tim]

Yes, I think to support light we'll be changing every 'bg-x' to 'bg- dark:bg-x'. We'll need to slowly work our way through each of these anyway, so not hard to prefix existing classes.

[benoitf]

I played over the week end to see some issues (and there are ;-)

it's something that we could render:

Screen.Recording.2023-11-20.at.19.03.40.mov