core: Add compatibility flags

[kjarosh]

Compatibility flags help configure Ruffle by enabling and disabling specific behaviors.

They are meant to be used for instance in the following situations.

1. They fix bugs in Flash Player that make some content misbehave. Note that in general we don't fix bugs in Flash Player -- we are bug compatible. However, there are examples where a bug is so sneaky, some content could have been created with an assumption that the bug doesn't exist and the bug affects it.

2. They genuinely improve the experience of using Ruffle at the cost of lowering compatibility with Flash Player.

3. They improve the "perceived" compatibility at the cost of the "real" compatibility. For instance, something does not work in Flash Player, and we make it work.

The main goal of this PR is to prepare for adding new flags in the future. This way we'll have a simple interface to configure such behaviors in the future. The most notable example would be https://github.com/ruffle-rs/ruffle/pull/18856 where we could add a compatibility flag which enables font fall back again for content that is not yet fully working in Ruffle due to various bugs.

[n0samu]

As a matter of UX, we should definitely give the right column a more descriptive name like "FP default" so people understand what it means (and I guess a tooltip with further explanation could be good too)

[kjarosh]

Forgot to add a screenshot!

The "FP" label does have a tooltip, I decided to keep the name short in order not to waste horizontal space (it has only a checkbox).

[emergence75]

can this also used in the actionscript classes ? if this is possible, it would be a nice solution for the correct hack here https://github.com/ruffle-rs/ruffle/pull/18495

[danielhjacobs]

Another good one would be https://github.com/ruffle-rs/ruffle/issues/3725

[thisisjonathan]

Would it make sense to make this part of the "Open advanced..." options instead of being a global preference? Imagine someone who changes a flag to make a game work and then later plays a different game forgetting that they changed it and then that game doesn't work right because of the flag. You'd also have to ask about the flags each time each time you're troubleshooting.

Another advantage of making it part of the launch options is that you could make it part of a Ruffle bundle, so you could bundle the game with the flags that are optimal for that game.

I'm working on a Flash editor based on Ruffle. Part of the appeal of Flash for me is that it (with some exceptions, like device fonts) works the same on my PC as on someone else's. It would be annoying if my games didn't work for some people because they turned on a flag a long time ago and forgot about it. It would also be bad if someone used my editor to make a game, forgot that they had a flag turned on and accidentally relied on the behavior with the flag turned on. Then when other people try the game, it doesn't work right for them.

[kjarosh]

Would it make sense to make this part of the "Open advanced..." options instead of being a global preference?

I think it would. I wouldn't say that this PR is like the ultimate implementation of the GUI for compatibility flags, I'd rather treat it as the starting point and ability to put something behind a flag at all.

The arguments you mentioned got me thinking and I'm rethinking whether saving compatibility flags to preferences is a good idea as of now.

Another advantage of making it part of the launch options is that you could make it part of a Ruffle bundle, so you could bundle the game with the flags that are optimal for that game.

I agree with that. But also note that the content deciding about stuff going on within Ruffle is not always the best idea. That's something we have to approach very carefully in order not to give too much control to the content.

I'd say if we go with this, each flag should be assessed individually whether it can be set within the content.