frontend: Demangle ScreenshotObj and OBSBasic

[cg2121]

Description

This adds a signal to ScreenshotObj, so it doesn't have to directly call OBSBasic.

Motivation and Context

Better code.

How Has This Been Tested?

Took screenshots to make sure they still worked.

Types of changes

• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

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

[PatTheMav]

The approach looks about right to me - the screenshot object cares for its own work and emits a signal about it, so the main window can handle that event and update itself accordingly.

However I'm concerned about a few things:

• The UI related functionality is implemented in ScreenshotObj's destructor. This is not an issue with the PR, but it somehow feels "wrong" to me. 😅
• But at least this allows the code the create a new instance of ScreenshotObj and connect to the screenshotTaken event, as the event would only ever be emitted when the object is destructed (which should probably happen after the function finishes).
• Shouldn't OBSBasic "disconnect" from the signal in its callback to avoid dangling connections for every screenshot taken? What is the state of the pointer during that callback, given that the signal happens during the constructor? emit doesn't block as far as I can tell.

Again, the signal-based approach is correct, it's the whole "emitting in the destructor" part that concerns me.

[cg2121]

According to https://doc.qt.io/qt-6/qobject.html#disconnect-3, Qt automatically disconnects signals when either of the objects associated with it are destroyed.

Nevermind, I get what you mean now, as the signal is in the destructor, and is non blocking, as far as we know.

[PatTheMav]

Please rebase.

[Warchamp7]

@RytoEX This may cause conflicts with #12067 so I'd suggest merging this second. I can tackle a rebase of this PR if there are issues.

[RytoEX]

@Warchamp7 I did try to apply both locally and they do conflict. Do you still want to block this on #12067 ?