Qt: Remove a few more instances of QDialog::exec()

[Pesa]

Need to do some more testing.

[stenzek]

FYI, it's only needed when the dialog is window modal. Application modal is fine. Hence why I didn't bother replacing these.

[Pesa]

Yeah, this PR isn't really meant to fix anything (nothing is broken here). I just feel it's cleaner to avoid the nested event loops started by exec() as much as possible. They're fragile and error prone, and Qt's documentation recommends using open() or show() instead. But I can abandon the PR if you're not sold on the idea, not a big deal.

[Pesa]

Sorry for the large-ish commit. To summarize:

• Extracted three two new classes: AudioStretchSettingsDialog, MultipleDeviceAutobindDialog and TextureReplacementSettingsDialog for better readability and separation of responsibilities. MultipleDeviceAutobindDialog is also used by the setup wizard so it must be exposed in a header, the other two are is hidden in an unnamed namespace. The diff in these three two cases looks large but it's mostly just code moved around with trivial renames.
• Changed a few dialogs to window modal: "add breakpoint", "advanced SDL settings", "LED settings", "new/edit game cheat code", "rename memory card file". Didn't see a good reason for them to be app modal. Moreover, these are now shown as sheets on macOS, which looks nicer.
• Four dialogs (AchievementLoginDialog, InputBindingDialog, PostProcessingSelectShaderDialog, and the "compatibility report") were already window modal, I just changed show() to open() for consistency. No functional change.
• The "About" dialog and the "Third-Party Notices" dialog are changed from app modal to window modal as well. I don't think these should be modal at all ("About Qt" isn't), so I might send another PR later on to make them non-modal.
• Centralized enabling WA_DeleteOnClose on message boxes. No functional change.
• Removed redundant modal / windowModality properties from .ui files. No functional change.

[stenzek]

I'm not really sure what the benefit to creating the new classes is - they're not moc-invokable, and there's no point keeping the pointers to the widgets around since they're not accessed afterwards?

[Pesa]

Good question. I was mainly following the pattern that when you have a .ui file you create a corresponding class with Ui::Foo as data member. Otherwise you have to allocate that Ui::Foo manually and keep track of it. In particular, I'm not sure when/where it can be safely deleted.

[stenzek]

You shouldn't need to keep the Ui::Whatever instance live. It allocates all the widgets on the heap and parents them to the widget that's passed in.

[stenzek]

This should not be removed. Might be easier to just merge and re-add it.

[Pesa]

I just moved it to QtUtils::NewMessageBox()