Add better support for strawberries

[maddymakesgames]

Strawberries (and other fields such as do_not_load) are currently just displayed as their entity IDs, as that is what is in the save file itself. This sucks to work with when actually trying to edit a save file since you don't know which strawberries are which or even if they are a normal strawberry or a golden strawberry. Especially since the entity IDs are in order of collection and not in the order in the pause menu tracker.

The goal is to be able to both say what type of strawberry a given entity ID represents AND to have them listed in the order they would appear in the pause menu, with goldens / silvers being listed first. So that then the editor can be simplified down to just a bunch of checkboxes for each strawberry. Ideally we would also be able to resolve all other entity ids to at least a room name and entity name. If we for some reason failed to lookup a strawberry we would default to the system we have now, but filling in any other entries with the data from the lookup if they succeeded.

This unfortunately requires parsing individual map files and storing the data for each individual entity in a database somewhere. The support for parsing maps has already been added, but parsing them in bulk and storing the data has yet to be added. This requires us to add support for parsing whole mods, and since I'm nothing if not thorough I would like all vanilla + everest data to be able to be accessed after reading in a mod, with a secondary loading method to only load in mod metadata and a list of maps. Ideally this would also support commonly-used mods like CollabUtils2 and AltSidesHelper.

We also need to have a list of all strawberry entities so that we can recognize them when parsing the map data. This unfortunately probably has to be done manually though I might ask around on the celeste discord to see if anyone has anything else to go through. We could also try parsing mod dlls to get all entities that extend the strawberry class but that would likely have false negatives that we'd have to manually fix.

I'm currently going to say that we will only parse map files on native versions of the gui app, having the user point us to the correct mods folder and then saving that so we can check if the list of mods has changed on startup. The database will be stored locally in some file based database.
Later this could be changed to have an api that will serve map information and that auto-updates every day or so.

The only issue that could arise here that would stop this method from working is that there might be a way to have entity ids desync from what is in-game but iirc this doesn't effect any maps made with ahorn or lonn and might have been fixed in everest. I think we can at least recreate the algorithm everest uses for creating entity ids so that we don't have any desyncs.