Performance: Optimize map::route and map::get_path_avoid.

[prharvey]

Summary

Performance "Increase speed of pathfinding substantially."

Purpose of change

These two functions are a giant hotspot when waiting in high traffic areas.

Describe the solution

This PR makes three two broad changes, somewhat interlinked:

1. The current code base uses get_path_avoid() to evaluate locations to avoid before running A*, however this defeats the entire point of A*. Replaced the function with lazy evaluation alternatives should_path_avoid() and get_should_path_avoid_functor() so the pathfinder can evaluate these locations as they are visited. This however means the pathfinder must evaluate more tiles, which brings us to change 2.
2. Aggressively increase the amount of information that is being cached in the pathfinder, and allow incremental updates to the pathfinder cache. This drastically reduces the per-tile evaluation cost of the pathfinder, which lets the change in 1 have a real impact.
3. Use a flood fill to detect areas where monsters are trapped, but otherwise want to leave. This is a common occurrence in underground locations with reinforced windows or bars, and results in the monster running A* on the whole room every tick. This marks such zones with a minimum bash strength needed to escape, and if the target is outside of this zone, pathfinding is skipped entirely. Flood fill is being moved to a separate PR.

Testing

Tests pass, game appears to work. Needs more playtesting from my end, so PR is still in progress.

Additional context

Flame graph before:

[prharvey]

There's currently a problem with this, in that some changes I made to monster's should_path_avoid got dropped on the floor when I was messing around trying to rebase stuff. I need to take some time to move those changes back in here.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[prharvey]

Superseded by #70274