libobs & frontend: fallback transitions when plugin is absent

[xurei]

Description

This is a follow-up of PR #9964 which allowed to keep the disabled transition in Safe Mode.

This PR adds a new source flag OBS_SOURCE_FALLBACK and a new function obs_source_create_private_with_fallback() in libobs.
The OBS_SOURCE_FALLBACK flag indicates that the original source type was invalid and replaced by another one.

It allows the frontend to load, save and render an invalid transition using "cut" as fallback.
This approach made the changes very limited and less prone to bugs.

The invalid/fallback'ed transitions shows the no_sources icon next to its name in the UI.
(I tried to change the font color to red, but apparently it does not work everywhere, I guess because of how Qt handles theming)

The properties UI shows an empty configuration panel when shown:

Motivation and Context

With the new Plugin Manager, it is now easier for the user to "mess up" with their configuration and remove transitions by mistake.

Besides, it makes the experience more unified, as the invalid filters and sources are not deleted when the related plugin is not present.

Also, as a plugin developer, any change that breaks the in-dev plugin causes all its transitions to disappear, which is annoying.

How Has This Been Tested?

I fully tested the changes on Linux (Ubuntu 26.04) with different scenarii:

• Start with one/multiple invalid transitions ☑️
• Remove an invalid transition ☑️
• Edit transition and press OK → settings are kept ☑️
• Add the plugin back → transitions are restored ☑️

⚠️ There is one thing I don't know how to test: before these changes, a transition would always have a registered source type. The fallback approach creates a source that is considered valid but with an id that is not registered.
However, I don't think it's a big issue, since Filters and Sources can already be in a similar situation.
I do believe that a second pair of eyes would be useful on this.

I explored different solutions to make as few changes as possible and ensure no bug are introduced.
This was the simplest solution I found, although I'm not fond of the obs_source_create_private_with_fallback(), to be fair. Maybe someone could use this as a base and find a better solution?

Types of changes

• Tweak (non-breaking change to improve existing functionality)

• Documentation (a change to documentation pages)

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.