frontend: Auto-discovery of registered services

[emilsas]

Description

This PR refactors LoadServices in OBSBasicSettings_Stream.cpp to dynamically discover and populate the stream services dropdown.

Instead of hardcoding check for specific service types (like the existing WHIP check), the code now:

1. Iterates through all registered service types using obs_enum_service_types.
2. Checks if the service type has a corresponding registered output protocol.
3. Automatically adds valid services to the dropdown.

To support this cleaner logic, a ServiceItemData struct (registered with Q_DECLARE_METATYPE) was introduced to replace the mixed usage of ListOpt enums and strings in the dropdown's QVariant data. This unifies how service metadata (type, ID, display name) is stored and retrieved.

Motivation and Context

Currently, plugins that introduce new service types (e.g., a new streaming protocol) do not automatically appear in the Stream Settings service dropdown. Developers typically have to modify the core OBSBasicSettings_Stream.cpp file to hardcode their service into the list.

This change allows any plugin to register a service and have it automatically discovered and listed in the UI, provided the underlying output protocol is registered. This decouples the frontend UI from specific service implementations and significantly improves extensibility for protocol plugins.

How Has This Been Tested?

Tested on macOS.

• Verified that standard RTMP services (Twitch, YouTube, etc.) load and work effectively as before.
• Verified that the "Custom..." option functions correctly.
• Verified that "Show All" correctly expands the list.
• Verified that a custom plugin registering a new service type (and protocol) automatically appears in the list without further code changes.
• Checked that saving and loading settings persists the correct service type.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Tweak (non-breaking change to improve existing functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to documentation pages)

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.

[ghostnumber7]

I tested on Windows 11 and it's working fine.