rtmp-services,frontend: Add data-driven VOD track support

[SpaceCrapaud]

Description

This PR adds a new supports_vod_track boolean property to the services JSON schema (v5), allowing streaming services to declare VOD track support directly in services.json instead of requiring hardcoded C++ changes.

Motivation and Context

Currently, VOD track support is hardcoded only for Twitch. Other services that support separate VOD audio tracks (for DMCA-safe music, multi-language, clean feed, etc.) have no way to enable this feature without modifying the OBS source code.

This change makes VOD track support data-driven, so any service can enable it by simply adding: "supports_vod_track": true to their service definition.

A hardcoded Twitch fallback is kept for backward compatibility with existing services.json files that don't define this property (and to avoid messing with Twitch's current implementation).
EDIT : The hardcoded Twitch implementation has been removed, Twitch VoD Track support is now defined directly in service.json, as intended with this PR.

Note that the label is still Twitch VoD Track, even if it's not for Twitch. I assume that making the label neutral for non-Twitch services across all locales would be better suited for a separate PR.

How Has This Been Tested?

Tested locally on OBS 32.0.4 on Fedora 43 and Windows 25H2 (dual boot).
AMD Ryzen 9 5950x - Nvidia RTX 3090 - 128Gb RAM

• Verified Twitch VOD track still works (via hardcoded fallback)
• Verified a custom service with "supports_vod_track": true enables the VOD track checkbox in Output settings

Types of changes

• New feature (non-breaking change which adds functionality)

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]

I'd like to think that this is a good idea, I'm unsure whether it wouldn't make sense to migrate Twitch in the service configuration file to supports this change in one fell swoop as well, rather then keeping the old hardcoded defaults around.

[derrod]

I'd like to think that this is a good idea, I'm unsure whether it wouldn't make sense to migrate Twitch in the service configuration file to supports this change in one fell swoop as well, rather then keeping the old hardcoded defaults around.

I think we should also move it for Twitch, yeah.

Edit: Perhaps I'd even go so far as to say make the naming more generic and just call it multitrack_audio_supported or something. Now that we're using ERTMP tracks instead of the old RTMP metadata based one, there's no real limit to how many tracks we can send. We can keep the verbiage/limitation in the UI of course, but for future use-cases we might go for a generic name in the backend.

[SpaceCrapaud]

Hi @PatTheMav @derrod !
Sorry for the delay, I was moving houses. Back in action now!
Thank you for reviewing :)

I removed the hardcoded Twitch implementation and fallback. It is now fully data-driven.

Regarding the generic labeling, as I would need to edit every locale to make it consistent, I think it's better to do it in a follow-up (I can prepare it and push it as soon as this one is merged, along with adding our service to the JSON).

Let me know if you prefer a complete PR. I'm not sure how far I'm supposed to go in one PR.