optimized map::generate a bit

[PatrikLundell]

Summary

None

Purpose of change

Improve performance of map::generate. This was triggered by #75166, but I don't consider this to solve that report.

Describe the solution

Replace repeated calls to MAPBUFFER.lookup_submap to see if it exists with a single check to a new submap_exists operation and then store the results in a vector that's then used for the subsequent existence checks.

Describe alternatives you've considered

• Waiting for more expert opinions on what to improve.
• Trying to see if anything can be done about map::is_main_cleanup_queued as that operation seems to use 5.28% of the CPU used in the last testing run (for the same reason lookup_submap costs a lot, i.e. a large number of calls). Out of scope for this PR.
• Restructure map::loadn code and usage to take the 3D nature of maps into account by loading vertical stacks of maps rather than one level at a time (when the maps support Z levels, of course), and possible also the fact that you don't load a single submap stack, but 4, 11, 21, or a full map's worth, and you ought to be able to gain some synergy by loading all of the stacks from a generated/loaded omt without reevaluating whether you need to generate/load it for every stack. Note such a change doesn't really relate to the recently introduced mapgen 3D support, as maps (and thus their loading) have been 3D for a long time before that change. Out of scope for this PR.
  Edit: Tried it and didn't it to work properly (light isn't set properly), but nevertheless, a performance test showed no significant performance change compared to the master code, presumably because juggling vectors to store state gobbles up the gains made elsewhere. Abandoning this as a failure.

Testing

Bumbling running of the VS profiler before and after modifying the code.
The results seemed to indicate a drop of the overall CPU consumption of map::generate from 15.17% of the CPU budget before the change to 5.28% after. An intermediate run after the changes to generate but before the addition to mapbuffer gave a result that was somewhere in between these two values.
Running the game by teleporting straight to the east to the edge of the revealed map (guaranteeing it hasn't been generated), starting recording and then keep moving east by keeping the movement key pressed until safe mode reported a monster showed it still hesitates at times (and I think it's probably on OMT boundaries). I can't say if the effect is smaller. I'd probably need a slower computer for that.

Additional context

It's quite possible the variability in results from different runs is high enough to make single measurements rather pointless.