display: support generic wlr-output-management-unstable-v1

[ezemtsov]

The display config UI only applied changes for compositors with a config-file backend (niri, hyprland, dwl). For any other compositor that supports wlr-output-management-unstable-v1 the "Apply Changes" button was silently a no-op.

Add WlrOutputService.applyOutputsConfig() as a high-level apply that mirrors the generateOutputsConfig() pattern of the existing services but applies directly via the protocol instead of writing a config file. Route the default case in backendWriteOutputsConfig() to it.

This change enables using dms-shell as a wayland compositor for emacs wayland manager (ewm).

[bbedward]

This is good, but the original reason to skip this was because of the potential risk in writing bad settings that could potentially damage displays (idk how possible it is exactly, but might need more oversight). And the secondary issue of persistence, that is the display settings won't be remembered at all. Would it make sense to have some memory and compare + apply settings at DMS startup (when settings are managed this way)

[ezemtsov]

Is it expected that the persistence peoblems would be solved by a shell? A compositor could just memorize the last setup for a unique set of EDID in the xdg cache folder.

As to the safety concerns, how would user send a faulty configuration from UI. Outputs only support a predefined set of modes, it's not possible to my knowledge to force them to work beyond their capacity.