feat: Add linear brightness transition option

[Nydauron]

Allows for the option for the backlight device to gradually reach its new brightness level.
Adds backlight_transition, backlight_transition_step_count, and backlight_transition_time_seconds as options to the configuration file.

New config options

• backlight_transition: the transition mode the backlight uses to move from the current brightness to the new brightness. One of "Linear" or "Instant". Defaults to "Instant".

The other two options are only read if backlight_transition is set to Linear:

• backlight_transition_step_count: How many steps should be used to get to the new brightness value. The higher the value, the smoother the transition appears. Keeping this at most to the monitor's refresh rate is advised. Defaults to 20.
• backlight_transition_time_seconds: The amount of time it takes to transition from the old brightness to the new brightness, in whole seconds. Defaults to 1.

[mikhail-m1]

thanks for the PR, I will try to review it properly ASAP. From the first glance I don't really understand why is separate thread is needed, and I would prefer to keep current mode as default.

[Nydauron]

From the first glance I don't really understand why is separate thread is needed

My inital thoughts were to decouple reading the light sensor + updating the Kalman filter and writing to the brightness API, because it prevents blocking between each action. If someone were to opt for a longer transition time and have a short light sensor read interval, in a synchronous threaded model, the brightness transition period would block any potential reads of the light sensor and updates to the Kalman values until the end of the transition.

I would prefer to keep current mode as default.

Will make that change 👍. I do think it would make it a bit hard to explain just by looking at illuminanced.toml since 2 of the 3 new config keys-value pairs will be a no-op on instant transition mode. Just something to note in #12 to include as well.

[mikhail-m1]

Sorry, I was really busy.

I still think we shouldn't use the separate thread. If we need more time for brightness change that for getting new target value, we could have several target values waiting in the channel. And the set brightness thread will chase the outdated values.
I think that limiting backlight_transition_time_seconds by read interval is good and simple approach.