Add per-game configuration override (for cpu pinning)

[mtslzr]

Elden Ring crashes when using gamemoderun with core pinning. I was using a script workaround to load a different config file on-the-fly, which was (at best) messy. This adds an option for per-game configuration files, living in ~/.config/gamemode.d/ (also ties to previous per-game use-cases, such as #388 and #570).

The change lets users pass GAMEMODE_CONFIG=x into Steam launch options, which then dynamically loads x.ini from the gamemode.d folder. Passes all tests (build, format-check, meson test). Confirmed working locally (Elden Ring now launches properly for me using GAMEMODE_CONFIG=eldenring gamemoderun %command%). Also tested against invalid names, invalid values, with and without overrides.

I originally looked at just checking the process name and using that to match to the file (so eldenring.exe would look for eldenring.ini). This worked in testing (gamemoderun sleep 5 would properly check for sleep.ini), but launching a game via Steam would look for env every time. This is because the game itself is a Windows process under Wine inside pressure-vessel, where the LD_PRELOAD never loads, so only the wrapper processes ever register with gamemode.

Additionally, names are restricted to [A-Za-z0-9_-] to prevent path traversal; config files can only be loaded from the gamemode.d folder (confirmed by testing with GAMEMODE_CONFIG=../badconfig and it being rejected). Verified the override holds across the reaper's periodic re-pinning and config reloads too.

This was intentionally scoped to only pin_cores to solve my personal issue with Elden Ring, and keep it more easily reviewable. Further keys can be added using the same pattern. Happy to adjust the approach; I would love to see a per-game solution for gamemode.

[mdiluz]

Cool idea! I like the implementation, it seems simple enough. I'm intending something similar in a fork, though I was gonna allow specifics within the existing configs, paired with an envar or a filter of some kind, like so:

[cpu]
pin_cores.eldenring=yes

But this approach offers similar versatility without the up-front complexity, so that's cool.

There's a few caveats that maybe are worth solving:

• Only loading gamemode.d from the user's config home is inconsistent with the other config files using this full list. That might be easy enough to do though with a simple refactor.
• GameMode won't reload (and re-apply) these files when changed, which is inconsistent with the other config files. This... may be harder to do than is worthwhile in the current codebase.
• I'm not a huge fan of the maintenance of two config formats with risk of divergence or inconsistency. Not 100% sure on the solution, but it would seem preferable to share more code if possible between the two.

[mdiluz]

have_pin_cores seems redundant, if pin_cores[0] == 0 then that's the same thing, surely? Or am I missing something.

[mdiluz]

This is because the game itself is a Windows process under Wine inside pressure-vessel, where the LD_PRELOAD never loads, so only the wrapper processes ever register with gamemode.

Actually worth mentioning this - I had assumed more recent code was accounting for this in gamemode-wine.c. Is that no longer working? Worth a bug report if so.