Turn off output when switching resolutions without input present

[nyanpasu64]

Sometimes I wanted to set the GBS-C's output resolution before powering on my console. Previously, the code would enable debug mode and disable the sync watcher. Both behaviors were very unexpected, and I had to figure out why my screen went gray and the GBS-C couldn't lock onto 15 KHz sources when I hadn't changed any settings.

This disables both unexpected behaviors, and turns off the output monitor as expected. It will switch to the selected resolution once an input shows up again.

Unfortunately this does not update the selected preset in the GUI. This only happens when doPostPresetLoadSteps() writes to rto->presetID, but we cannot call doPostPresetLoadSteps() since it enables the output (showing a green screen) even if previously disabled. As a stopgap solution, I clear rto->presetID, and update the web UI to clear the currently highlighted button when the server indicates it's currently on preset 0 (no output mode). Once an input source appears, the clicked button is applied and highlighted.

I hope this will never clear the highlighted button when a preset is actually active, but updateWebSocketData() { switch (rto->presetID) sends the GUI an unrecognized value. Who sets rto->presetID = 0? The only code I've seen so far is applyPresets() with no input present (added in this PR), or setup() on startup (before a preset is applied). There might be code elsewhere which loads rto->presetID = expression with a value of 0 or another unrecognized/invalid value. But in my testing I've never seen all resolution/load buttons on the web UI disappear so far, so this should be safe?

Fixes #414.

[nyanpasu64]

As a sidenote, when loading custom presets, when no input signal is present, clicking "load preset" highlights the underlying resolution (GBS_PRESET_ID) for a few seconds (oddly enough), before highlighting "load preset". You have to wait 30 or so seconds after the input video stops, while the GBS-C scans for inputs and ultimately gives up and says <reset> Scanning inputs for sources .... Only then, loading a preset says Source format not properly recognized, using fallback preset! and highlights no preset (and would previously break).

Picking a fixed resolution immediately triggers Source format not properly recognized, using fallback preset!.

IMO fixing this is not really in scope of this PR:

• I haven't debugged the root cause of why loading a custom preset before <reset> uses a stale input resolution.
• The changes in this PR improve the user experience, even without this new case fixed.
• Highlighting the wrong button after turning off your console and loading a custom preset is confusing to the user, but not a persistent bug (I tested that turning your console back on works normally), unlike how disabling sync watcher and enabling debug mode breaks future gameplay.