feat: adds an alternative organized folder support for menu backgrounds

[KrutzOtrem]

Although Robin had a similar, or rather, more elaborate PR for a more organized theming system, I assume the plan is not to go that route and complicate things.

So, rather than proposing a complete overhaul, I’m suggesting a simpler, extremely non-intrusive, and entirely opt-in approach to theming. The only addition would be allowing users to place organized backgrounds inside /Themes/<theme-name>/ and select them from Settings > Appearance instead of individually copying them into relevant .media folders (well, alternatively to doing that). There is no added functionality other than that.

├─ Themes/
│ ├─ theme-name/
│ │ ├─ GBA.png
│ │ ├─ GBA-list.png
│ │ ├─ GBC.png
│ │ ├─ GBC-list.png

This is completely backward-compatible for two valid reasons. It allows the current method to always take priority over the selected theme, so existing themes can continue to be used freely. It also lets users override default backgrounds for secondary folders that use the same emulator tags. That is to say, although GBA.png would globally apply that particular image to any folder-name (GBA) ROM folder, if a user also has a secondary folder, say, Best 10 Games (GBA), they could still use the existing .media folder to override the globally applied new folder image.

It is my observation that, in some shape or form, simple or complicated, users already use background images in almost all cases, at least judging from what I have seen on Discord and the subreddit. However, they usually do so through third-party PAKs. Those who do not use the PAK store rely on copy-pasting individual images, which in some cases, especially when used together with bglist, can amount to more than 60 or 70 images. This should solve both issues, help Aesthetic maintainers design their code in a simpler way, and relieve them of the need to delete, store, or manage old files. It also helps that users would not have to remove their old images just to test another theme.

This update went through several iterations. I did read the source code, and it looks unproblematic to me. The tests are okay as well. However, I mainly write in Lua rather than C, so being able to read the code is a completely different matter from seeing the underlying problems. Let me know the issues so I can go over it a couple more times, if you are interested in this update. Otherwise, I can pull it back.