Add benchsimulate command

[janisozaur]

Adds a new command, benchsimulate, that starts benchmarking
UpdateLogic() function.

[ZehMatt]

Is there a way to annotate/tag a certain event during the profiling? The UpdateLogic function has like a bunch of sub-updates and it would be nice to know which one of them performs terrible, heres a list:

date_update
scenario_update
map_update_tiles
map_remove_provisional_elements
map_update_path_wide_flags
peep_update_all
map_restore_provisional_elements
vehicle_update_all
sprite_misc_update_all
research_update
ride_ratings_update_all
ride_measurements_update

There are quite a few, so it would be nice to know what is what.

[janisozaur]

I see two ways to provide this:

1. Add explicit benchmarks for each of those

• note that testing a single function out of the bunch could lead to results different than the current approach of using UpdateLogic(), as they likely touch same data (think: updating the peeps but not vehicles they're in could lead to unexpected results)

2. Use manual timing (a feature of gbench) and collect timings for each relevant section

• this could be reused to expose some timing details in-game (see how it's done in OpenTTD https://imgur.com/gallery/tyI3Htc)
• collect them to a map so they values can be given names without having to change underlying structure
• display them using gbench's custom counters

[AaronVanGeffen]

This is essentially doing the same thing as #10281. We need to decide which to merge.

[tupaschoal]

This is looking very neat

[tupaschoal]

Maybe we should have something that converts from an enum of LogicTimePart into the corresponding string, to be less error prone. That would also allows us to do a for on the enum updating all counters

for (<all_enums>)
    state.counters[ToLogicPartString(enum)] = accumulator(enum);

[tupaschoal]

I've dropped the issues where you commented, but there are still a few to tackle.

[janisozaur]

I've just updated, think it should be ready now