frontend: Fix a crash when user cancels to save changes in settings

[suogesi]

Description

Settings > Video > Output (Scaled) Resolution is a QComboBox, which has a dropdown and may be editable or not. If some settings make it not editable meanwhile change its value, when user tries to close settings window and select "No". OBS always tries to write preview value back, even if it is not editable now. This will cause a crush.

This PR adds a check of nullptr so it won't cause a crush anymore.

Motivation and Context

#13367

How Has This Been Tested?

1. Switch Settings > Stream > Service to "YouTube - RTMPS".
2. Write "3840x2160" in Settings > Video > Output (Scaled) Resolution .
3. Switch Settings > Stream > Service to "Facebook Live".
4. In the pop-up window, select "Yes" to accept changing resolution to 1920x1080.
5. Click X to close settings window.
6. In the pop-up window, select "No" to cancel saving changes.
7. OBS won't crash anymore.
8. Open the settings again. The settings don't change, as it wasn't be changed.

• OS: Windows 10
• OBS Studio version: 32.1.2

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

There seem to be multiple instances in the settings window implementation where code has to dance carefully around the "editable" state of the resolution comboboxes.

The code usually explicitly calls isEditable to figure out whether it might potentially yield text widget before accessing it. So I guess it would be more canonical to use the same approach here.

[suogesi]

It makes sense. Now OBS will gently ask if output resolution can be edited.