unify behavior of preference options

[RJ Skerry-Ryan]

We have a huge variety of inconsistency in the preference pages. There are 4 main events the preference pages get and currently every page treats them differently.

* Update (load the latest config settings into the GUI widgets)
* Apply (take the GUI widget settings and write them to the user config, live COs)
* Cancel (take changes since last Update and revert them)
* Reset to defaults (reset the GUI widgets to default values, then call Apply to write them to the config)
* Show (the preferences dialog is shown to the user)
* Hide (the preferences dialog is hidden from the user)

- When the user opens preferences, a Show and Update event is delivered to every page.
- When the user hits Apply, an Apply event is delivered to the current page.
- When the user hits OK, an Apply and Hide event is delivered to every page.
- When the user hits Reset, a Reset event is delivered to the current page.

The GUI widgets themselves are also quite inconsistent on whether they trigger updates if a user changes the widget or if code changes the widget. Code changing the widget triggering slots can lead to circularity and so all widgets should only trigger slots if a user changes them, not if code does.

All the pages do different things on update and apply. Some of them update widgets and config/COs on update, some of them update widgets only but because widgets trigger on code changes, that also updates the config and live COs. It's a big mess.

We also need to track dirty state uniformly across all pages. That way we can enable or disable the apply button if the page is clean.

[ronso0 (ronso0)]

... and warn when leaving a page with pending changes.

[ronso0 (ronso0)]

a few PRs trying to unify the behaviour:
https://github.com/mixxxdj/mixxx/pull/4721
https://github.com/mixxxdj/mixxx/pull/4667

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7440