[6.0 backport] daemon: Avoid constantly locking ddcutil display handles
In order to make this backport of MR !333 (merged) happen, I added to the branch a cherry-pick of commit db4a6c79 (as separate commit) as well as the function signature change of generateDisplayId() from commit a6b9cf5f (merged into the main commit).
Paths are not the same in master anymore, and the old version of DDCutilDisplay still uses r/w locks instead of a worker thread for calling the ddcutil brightness setter. Nonetheless, the changes themselves transferred to the old version without significant conflicts and I'd consider this safe enough to have it on Plasma/6.0 as well.
Since libddcutil implemented functionality for per-monitor device lock files, other programs that are also using libddcutil (such as the ddcutil CLI itself) were blocked from performing monitor commands because PowerDevil kept all its handles open.
The better way of interacting with libddcutil as a long-running program is to store a DDCA_Display_Ref for each monitor in question, use it to get a temporary display handle, and close it again.
Now we can peacefully coexist with other libddcutil programs, and users can e.g. query their monitor properties again.
As a slight downside, this means it's possible for another program to set display brightness independently without PowerDevil noticing. That seems like a smaller evil though, and can't be fixed by simply using libddcutil itself as it cannot signal any VCP changes. Common infrastructure such as digitaltrails/ddcutil-service or a future kernel DRM interface for DDC/CI could help to mitigate this.
BUG: 481793 FIXED-IN: 6.0.4
(cherry picked from commit db4a6c79)
(generateDisplayId() changes extracted from commit a6b9cf5f)