Implement quest towns and buildings in terms of extended data instead of putting them in separate places

[Ruin0x11]

Having lots of state in random places is bad when you end up removing whole areas, because you need extra logic to deal with the cleanup of that state so invalid areas don't get referenced. Building.remove_for_area() ought to be unnecessary, because there should be no easy way for the building to get out of sync with the liveness of the area if it's deleted.

The implicit thing that's being modeled with registered quest towns and buildings is that they carry some extra "metadata" that is linked to an area/map, but isn't part of the schema of either. I'm wary of just making them official fields of InstancedArea/InstancedMap, because applying that methodology to modding doesn't scale. The problem is: if you want to have some extra information saved about a map or area that's not part of the base game, you have to put it somewhere, and at present there isn't a way you can put it in the map/area instance itself in a standardized way, so you have to keep the state outside of the instance. But that means the state can get out of sync if the map/area is deleted.

So I think that there needs to be a standardized way to extend maps and areas with new data. There's ModExtData but it's pretty unstructured at the moment. There's no separation of concerns; each mod would get its own global namespace to put whatever it wants there. The best I can come up with right now is the capabilities system mentioned in #15 (comment). But assuming that works, it would mean the data would be stored on the instance itself and would get cleaned up automatically when the area/map is deleted, so long as there isn't any other bookkeeping going on. Getting the list of buildings would then mean iterating the list of areas and filtering on the ones where area:has_capability(IBuilding) are true.