cmake: Fix bundling of scripting files on macOS

[PatTheMav]

Description

Adds necessary code to the macOS-specific CMake helper to ensure that scripting libraries are copied into the application bundle's "PlugIns" directory.

Motivation and Context

Scripting libraries for Python and Lua need to be placed in the runtime plugin directory of the application bundle on macOS.

This was previously handled by the same code that handles the first- party runtime modules, but the scripting libraries are not libobs modules and thus need to be handled separately.

How Has This Been Tested?

Tested on macOS 27. Fresh build had both _obspython.so and obslua.so in the "PlugIns" directory of the generated application bundle.

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.

[RytoEX]

cc @FiniteSingularity @jcm93

[jcm93]

Looks fine to me.

Was curious why this didn't break on Windows and Linux, but it looks like Windows and Linux already had special handling for these two targets; this PR goes about things slightly differently but ends up with the same result.

If we wanted to handle these two targets the same way as Windows and Linux, the Xcode embed calls would go in this area where there is already handling for obslua and obspython.

To be clear, either way seems fine; just filling in context that might be useful to anyone looking at the build system.

[PatTheMav]

Looks fine to me.

Was curious why this didn't break on Windows and Linux, but it looks like Windows and Linux already had special handling for these two targets; this PR goes about things slightly differently but ends up with the same result.

If we wanted to handle these two targets the same way as Windows and Linux, the Xcode embed calls would go in this area where there is already handling for obslua and obspython.

To be clear, either way seems fine; just filling in context that might be useful to anyone looking at the build system.

That wouldn't work conceptually because in contrast to Windows and Linux, macOS uses application bundles (and not plain directories) and the obs-studio target does not exist when either the obslua or obspython targets have their target properties set (you would not be able to say "what is the location of the "PlugIns" directory of the application bundle of the cbs-studio target, because the target does not exist yet).

That's why so much stuff has to happen as part of handling the properties of obs-studio- it's only when CMake is working on that target that we can assume other targets to exist and then retroactively add them to the dependency line.

This absolutely will break if the frontend directory is ever entered before the plugins directory and is an unfortunate side-effect.