WIP Refactor repeated map.ter .furn .*_at calls

[sparr]

Summary

None

Purpose of change

A lot of places in the code call the same lookup functions for map data repeatedly. This makes some of those sections hard to read if the parameters are not short. It also results in lack of optimization in some cases

Describe the solution

Repeated calls to the map methods in question are replaced with one call and mostly const mostly references. A lot of existing calls that get copied to local vars are are converted to const references.

A dozen mapgen functions with identical has_vehicle_collision have been refactors to inherit from a new class that provides that method.

Describe alternatives you've considered

Caching more results in the map classes is an option but would be much more complex.

Testing

Automated tests pass. I played for a while with the changes, and continue to do so. This will be draft until I'm more confident I've reviewed and tested as much as I can.

Additional context

I skipped a few places where the repeated calls appear in the middle of a series of conditions so it would be more complex to break them out without changing the order of execution.

[PatrikLundell]

I'm not a fan of cramming assignments into "if" statements, because it's messy, ugly, and confusing to read. I do, however, think breaking out constants prior to the "if" statements is readable and makes sense (when used more than once, of course, which is not an issue here).
If it isn't considered to make sense to break out constants before the tests (e.g. because it's a long if/else chain) I would drop the constant altogether, unless it makes sense to define it after the "if" test for usage further down. The gains are minuscule anyway.

Saw at least one place where assignment of constant resulted in removal of preexisting ugly assignment inside "if" statement. Good!

Note that I have no official capacity, so my opinions can easily be overridden.

[sparr]

@PatrikLundell I understand your concern, and share it to a lesser degree. I did decline to implement the increasingly atrocious syntax necessary to account for cases like these without performance costs:

if( foo || here.ter( p ) == x || here.ter( p ) == y ) {} else {}
if () {} else if( foo || here.ter( p ) == x || here.ter( p ) == y ) {} else {}
if () {} else if( foo || here.ter( p ) == x || bar || here.ter( p ) == y ) {} else {}

I'd be fine with getting rid of the constants-in-conditions, and I can make educated guesses whether it's more efficient to define the constant in advance (when it might not be needed at all) or make the call twice in the conditions.