Add wayland option in launch options

[Fredolx]

Description

This PR adds a wayland option per-executable in the launch settings.
It is useful if the global wayland settings is useful for most executables in a bottle, except a few (white screen, crash)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.
Provide instructions so we can reproduce.

• Create a new bottle
• Enable wayland globaly on the bottle
• Add an executable with "Add shortcuts"
• In launch option, toggle off the new wayland option.
• Launch the executable

[mirkobrombin]

I was not aware the WAYLAND var env was a thing D: Not sure how to test it since I already use wayland only, I'll wait for a second opinion. Thanks!

[louzt]

Architectural Review & Second Opinion

This PR provides a highly necessary feature for per-executable runtime isolation. In complex winebottles, a global Wayland configuration might work flawlessly for 90% of the applications, while specific legacy executables or media players suffer from rendering glitches (e.g., zero-frame white screens or window lifecycle crashes). Myself had this problem on SmartersIPTV app time ago, sometimes worked, sometimes clics didnt work, sometimes white screen, most of times works but... enough for me and reason why i change my client towards open-tv/fredtv months ago.

Allowing a granular, per-executable override to safely decouple specific processes back to XWayland/X11 without mutating the entire bottle layer is the correct architectural approach in my op.

Clarification on the WAYLAND Environment Variable:

To clear up any confusion regarding the execution block: WAYLAND is not being introduced here as an upstream Linux OS or Wine native environment variable. It is being leveraged strictly as an internal transport token inside Bottles' internal environment dictionary pipeline to safely pipe the evaluation state from executor.py down to winecommand.py without breaking pre-existing serialization signatures.

Even though it gets exported to the spawned child process environment block, it remains completely inert to the host OS (which relies entirely on WAYLAND_DISPLAY) but flawlessly fulfills its role as an internal state conduit.

Resolution Matrix Workflow:

flowchart TD
    A["Launch Executable Triggered"] --> B{"Is per-executable wayland explicit?"}
    B -->|Yes| C{"Does it differ from global?"}
    B -->|No| F["Fallback to Global Parameter"]
    
    C -->|Yes - Override| D["Inject internal flag: WAYLAND = 1 or 0"]
    C -->|No - Redundant| F
    
    D --> E["winecommand.py reads flag from environment"]
    F --> G["winecommand.py reads global via getattr"]
    
    E --> H["Execute: apply_wayland_preferences"]
    G --> H

Loading