Qt: Fix some options not changing enabled status on game start.

[TryTwo]

When a game starts and the game config is loaded, the signal block on ConfigChanged will prevent options from updating properly, such as triggering an enable/disable for some options that are linked. The signal block was used to prevent triggering a Save.

Programmatic updates that change the value to something different from the config need to be saved. "VBI skip" triggering "skip duplicate XFBs" is one example.
ConfigChanged updates change the value of an option to be consistent with the new config, and should not trigger a Save, because that triggers another ConfigChanged.

I dropped the SignalBlocker in favor of an m_updating bool, to only block the re-saving.

A different solution would be to just shove every enable/disable/etc check under the ConfigChanged signal. I don't really like how bloated it's getting though.

[TryTwo]

@JosJuice Could you check this bugfix? I think it's safe, because the m_updating is set and removed in the same function.

[JosJuice]

Let's say that, for instance, we're executing ConfigBool::OnConfigChanged, and it calls setChecked with the same value that the QCheckBox already was set to. Does this trigger the QCheckBox::toggled signal? If yes, you should add checks in the classes that inherit from ConfigControl so that they don't emit any signal in this scenario, to avoid sending "useless" signals to other objects that just waste time. (Or am I overestimating how many other objects there are listening to these signals?) If no, then the comment here appears to describe a scenario that cannot happen:

dolphin/Source/Core/DolphinQt/Config/ConfigControls/ConfigControl.h

Lines 61 to 62 in b07170d

	// Avoid OnConfigChanged -> option changed to current config's value -> unnecessary save ->
	// ConfigChanged.

[JosJuice]

Also, it would be helpful to put the PR description in the commit. Currently, the commit message lacks a lot of the details that you've taken the time to write out for the PR description.

[TryTwo]

toggled and others like currentIndexChanged only signal if the value changes. The time it matters is when loading a new config, such as when starting a game up. The config will have all the correct values, but some options will have their values changed to match that. We don't want to re-save, but we do want enabled status to be updated, which also uses the toggled signal.

I could also check that the value being saved is actually a new one every time Save is called, and return early if it's the same.

There are not that many options that check for enabled status and the like. There are a few that need to change themselves based on other options too. It's just important to avoid unnecessary ConfigChanged signals because that hits a ton of stuff.

[JosJuice]

I think this is fine as it is then.

[TryTwo]

Updated commit message