Provide a way for headless outputs to be destroyed

[RedSoxFan]

This is a follow up to #5483, where there was an attempt to remove a headless output using output HEADLESS-1 disable. Since disabling a headless output does not make sense and is not supported by wlroots, there should be a way to destroy these outputs.

We'll likely want something like output HEADLESS-1 destroy. The output command does not currently have any action-only subcommands so we'll likely want to add support for those. Unfortunately, the output command also has the unique property of allowing subcommands to be chained (for backwards compatibility) which may complicates things. We'll likely want to prevent this chaining for action-only subcommands and make them two different branches.

[emersion]

Potential alternative solutions:

• Make disabling a no-op in the headless backend?
• Support disabling a Sway output even if wlroots can't?

Not necessarily exclusive with a way to destroy headless outputs.

[Hubro]

Any workarounds available for this? What do I do when I'm no longer using the virtual output? Do I just have to reboot to avoid having a workspace permanently bound to an invisible display?

[emersion]

Send a patch?

[ldelossa]

Any workarounds available for this? What do I do when I'm no longer using the virtual output? Do I just have to reboot to avoid having a workspace permanently bound to an invisible display?

Just spitballing, but you could assign some impossible position like 9999x0 to the headless and reconfigure sway. Then just move any workspaces that were there to your normal screens?

[Hubro]

Any workarounds available for this? What do I do when I'm no longer using the virtual output? Do I just have to reboot to avoid having a workspace permanently bound to an invisible display?

Just spitballing, but you could assign some impossible position like 9999x0 to the headless and reconfigure sway. Then just move any workspaces that were there to your normal screens?

I tried something similar a while back, I think I set it to 1x1 and placed it top right of my main monitor. Unfortunately it caused a slew of bugs, I think some applications would constantly crash, even though I didn't place them on the 1x1 monitor. It's also too easy to accidentally move a window to the invisible monitor, in which case they would usually crash/freeze indefinitely.

I've just stopped using virtual monitors until this feature is implemented, it's more trouble than it's worth.