Settings: allow `$options` to be populated at runtime

Summary

$options combobox values are declared in the mod source and fixed at install time. That means a mod can't offer a picker over anything it discovers on the machine. I'd like a way for a mod to supply options at runtime — for example an optional export the settings UI calls, Wh_GetSettingOptions(name).

Filing this as the ambitious one of a small batch. It is clearly larger than the others and I'd understand it being declined or deferred; the ones alongside it stand on their own.

Why

$options is the right control whenever a value must be one of a known set. But "known" currently means "known when the mod was written", which excludes everything interesting about the machine the mod is running on:

• installed applications a mod can target
• files in a folder the mod reads
• connected monitors, audio devices, profiles
• window classes or processes discovered at runtime

For those, authors fall back to a free-text field the user must type exactly, which trades a discoverable, unmistakable control for one that silently does nothing when misspelled. The mod usually can't even validate it well, because by the time it reads the setting it isn't in a position to tell the user.

Evidence

I'm building toward a small patch registry: CSS patches live as files, and the user picks which to apply per application. The natural control is a checkbox list or a multi-select of the patches present on disk — which is precisely what can't be expressed, since the patch set changes whenever a file is added.

The workarounds available today, and why each falls short:

1. Free-text patch ids. Typo-prone, and the mod can only report a mismatch to a log the user isn't reading.
2. Bake $options into the source. Adding a patch then means editing and reinstalling the mod, which defeats the point of a file-driven registry.
3. A directory convention — apply everything in a folder, disable by renaming with a leading _.

I shipped (3). It works and needs no engine change, but the enable/disable affordance is now "rename a file in Explorer" rather than a checkbox in the settings UI, which is a real step down for anyone who isn't the author.

Note that alpha.2's relaxation of settings-array indices (undeclared rows are now writable — thank you, that was the other half of this problem) makes the storage side flexible. It is now only the presentation side that is fixed at install time.

Suggested shape

An optional export the settings UI calls when rendering, mirroring how mods already expose lifecycle functions:

// Called by the settings UI. Return NULL / do nothing to keep static $options.
BOOL Wh_GetSettingOptions(PCWSTR settingName, WH_SETTING_OPTIONS* out);

Open questions I don't have a good answer to, and which may well make this not worth it:

• Where does it run? The settings UI is not inside a target process. Calling into a mod outside its injection context is the hard part of this request, and possibly the disqualifying one.
• What if it's slow or hangs? Needs a timeout and a fallback to static options.
• Refresh semantics. Once when the settings page opens is probably enough.

A cheaper alternative that captures much of the value: let a mod write a candidate list to a known location, and let $options reference it — $optionsFrom: "%LOCALAPPDATA%\\my-mod\\options.json". No cross-process call, no lifetime questions, and the mod controls the contents. If the full version is too invasive, this variant would still turn (1) and (3) above into a real picker.

Tested on 2.0.0-alpha.2.