Feature/add color settings

[juv]

fixes #137, fixes #134, fixes #133, fixes #132, fixes #128, fixes #122, fixes #115, fixes #114, fixes #113, fixes #110, fixes #107, fixes #98, fixes #95, fixes #67, fixes #60, fixes #55, fixes #36

[SwatX18]

Heads-up before this branch gets merged: I believe it carries a defect that silently destroys monitor calibration, and I think it's the cause of #128 and probably #131. Full analysis in #128; the short version here.

RestoreWindowsColorSettings doesn't restore — it synthesises. It builds a ramp from the three Windows-level sliders via CalculateLUT and writes that, rather than replaying what was on the display. DeviceGammaRampHelper.GetGammaRamp exists in this branch but has zero callers.

The reason that's destructive rather than approximate: CalculateLUT(0.5, 0.5, 1.0) — the default slider positions — reduces to exactly result[i] = i * 257, which is the identity ramp. I verified on real hardware that an uncalibrated display reads back as precisely that. So on the first game exit, any ICC profile, f.lux or Night Light ramp is replaced with a flat linear one, permanently, with nothing remembering what was there.

The feature ships off by default (neverChangeColorSettings defaults to true), so the blast radius is limited to people who deliberately enable it — but for them it's silent data loss on the first alt-tab out of a game.

Three smaller things in the same file, all of which I hit while fixing the above:

• ReleaseDeviceContext calls ReleaseDC on a handle obtained from CreateDC. That pair requires DeleteDC — ReleaseDC fails and the DC leaks on every apply.
• SetGammaRamp(Screen, int, int, int) guards with brightness == 0 || contrast == 0 || gamma == 0, which rejects a legitimate brightness of 0. Looks like it was meant to be < 0.
• The int overload forwards positionally into the double overload whose parameter order differs from its own doc comment — easy to transpose silently.

I've fixed all of it on a fork (SwatX18/vibranceGUI#8 for the gamma restore itself), with a regression fixture that drives full apply/restore cycles against fake display devices so the state machine is covered, not just the arithmetic. Both of the subtler regressions fail that fixture when reintroduced.

Glad to open a PR against this branch if that would help — say the word and I'll port it. I held off because the fix builds on the three smaller fixes above, so it would either bundle them or need working around, and that's your call rather than mine.