Make NavMap objects request sync only on demand

[smix8]

Replaces brute-force sync check loop with a self-listing system where each map navobject is responsible for its own sync, requesting the sync only on demand once.

Previously each NavMap::sync() the map looped over every single navobject on the map on the main thread. For each physics step it looped over all regions, links, agents and obstacles, to check if any of them are dirty and needed to be synchronised. If dirty it called their sync function or whatever equivalent on the main thread in the middle of the physics step iteration.

Let's just say having potentially thousands of unchanged navobjects on the map checked every single physics step and updated on the main thread was less than ideal. Doing all the more costly sync updates while blocking physics on the main thread was even worse. Who would have guessed?

This PR does not change things about the threading but it prepares the base. Even if performance was a minor incentive for this change the current system was also not long-term sustainable with more and more different navobjects added or additional sync points required for async updates. This PR mostly copies how this is handled by similar servers or classes.

[fire]

Do you have a method for testing this like a test project?

[smix8]

Do you have a method for testing this like a test project?

For stability test just spawn, change, and delete (ten) thousands of NavigationRegion3D, NavigationLink3D, NavigationAgent3D and NavigationObstacle3D nodes at random intervals between physics steps until your CPU catches fire.

Also helps when the reported debug monitor navigation section numbers make sense after every change.

The --test -test-suite= *[Navigation]* already confirmed that there are no (major?) sync errors because those tests expect a valid result directly after a single sync, else the tests start screaming which I had multiple times while working on this.

Performance testing in a vacuum is mostly pointless for this PR as it was sliced from a bigger PR for async synchronisation missing the main accompanying pieces. I am piecemealing that larger PR atm with smaller PRs like here to escape the rebase hellscape as best as I can.