Add EasyRPG "Patch" Flag to conditionally enable/disable some of our extensions

[Ghabry]

I added a new --patch-easyrpg flag for enabling EasyRPG Extensions. For now I consider EasyRPG a "patch". This engine vs. patch split should be revised some day with a "features" system.

Commit 2 is worth a discussion:

1. What is imo obvious is locking our custom event commands behind this flag. That is consistent with all the other commands we have.
2. I locked the big charset "$" feature behind the flag. Currently I only know two games that use this: Deep8 and CU. Deep8 uses a fork of the Player, so doesn't matter. CU is still in development. -> Do not think this will break games if we notify CU in-advance.
3. Only EasyRPG and Maniac Patch like 32 bit PNGs. I print now a warning when such an image is loaded without these patches on. I got this idea when there was a discussion about a bogus patch for Yume2kki: The dev only used EasyRPG Player for testing and when it was published they received reports that the game crashes in RPG_RT because of 32 bit images :sweat_smile: -> Not 100% sure if this will break games. For Deep8 and CU same as above. This restriction could be relaxed, e.g. only report about it in TestPlay mode and ignore it in "normal mode". I just think this is useful for gamedev.
4. Is there anything else that should be "locked" behind the EasyRPG flag? Imo the flag should be only for features that can break games. What will stay enabled: The translation feature as you cannot run into this by accident (also this would break games, it is widely used already). Custom resolution is also always on because it is used by the setting scene (and you can already opt-out via WinW=320,WinH=240 as Yume2kki does).

---

Less controversial (I could split them in a different PR, only added them here because I touched big charset by the easy-flag).

About Commit 1: Obtaining the bpp (depth) is for this 32 bit warning message mentioned above. That output struct API is based on support for animated bitmaps (APNG, Asesprite). That struct will get more fields to support this. Keeps the argument list short.

Commit 3 fixes big charsets on looping maps. Commit 4 makes it a bit faster. Imo the solution is not that great. It works by creating even more "clones" also in negative direction, not just positive. The performance impact should be minimal as they are usually culled when they are out of bounds.

[Mimigris]

Idea of a thing that could be locked: audio formats not supported by the original engine (e.g. ogg). Could search for other files in the directory with the same name that is supported by the original engine. Not implementing this wouldn't break a lot of things since only two commands (Control Variables: MIDI Tick and Conditional Branch: BGM has completed a loop) do things with the music selected, so I'm not sure if it would make sense to implement. Related to the language folder: since this feature is only supported by the Player and not by RPG_RT, detecting if the picture taken from there is a 32 bits PNG to do the check should likely be disabled since it doesn't impact anything, just a thought on that.

[Ghabry]

Good point about translations allowing any image file.

Disabling certain audio formats will break the web player because it is recommend to convert all the music to ogg or opus to save space.

There is also a patch for RPG_RT called audioremony that adds more audio formats which would require detection in that case.

[Mimigris]

It seems that using a translation that has 32 bits PNG without using the easyrpg flag will only remove the warning: the picture will still be not loaded as if it the game was not planned for that. (If you want to test that, you should be able to do it by using a Russian translation from YNOproject).

[Ghabry]

Ouch yeah you are right. Somehow the brace is at the wrong location.

Must have messed up a rebase. 🤔