Fix thread-use causing navigation source geometry data corruption

[smix8]

Fixes navigation source geometry data corruption caused by thread-use that changed vertices or indices while the source geometry data was used in a parsing process or read from by the navmesh baking.

resolves #90934

Pairs with #93392

• Extends the existing NavigationMeshSourceGeometryData RW locks to make data thread-safe where relevant.
• Adds C++ functions to set_data() and get_data() in one call to avoid desync.
• Updates navigation mesh generator baking to use the new, more thread-safe functions.

The issue was the same as with the navigation mesh. If users kept a source geometry object around to add procedual geometry for baking, e.g. with a chunk system, they did run into conflict when using a thread for the procedual "parsing" or baking step by corrupting the source data.

I tested this and the other PR together by baking various large godot 3D demos while also adding custom geometry without a lock issue or crash, still more testing is welcome.

TODO would be to extend to the navigation mesh generator parsing as well but that requires also changing the nodes so postponed for now as that part needs to run single-threaded anyway due to the SceneTree.

[fire]

I am not able to evaluate / test this, but navigation is important.

[RandomShaper]

Looks good and makes sense at first glance.

[akien-mga]

Thanks!