Tests: Remove NavigationRegion3D race condition that fails on CI

[akien-mga]

As the comment pointed it out, it's a race condition, and evidently no, "it's [not] fine" ;)

It occasionally fails on macOS editor builds with:

./tests/scene/test_navigation_region_3d.h:79: ERROR: CHECK_EQ( navigation_mesh->get_polygon_count(), 0 ) is NOT correct!
  values: CHECK_EQ( 2, 0 )

./tests/scene/test_navigation_region_3d.h:80: ERROR: CHECK_EQ( navigation_mesh->get_vertices().size(), 0 ) is NOT correct!
  values: CHECK_EQ( 4, 0 )

[AThousandShips]

Would be interesting to investigate why it fails on macOS specifically (or rather, why it's more likely to fail there)

Alternatively we could comment it out with a FIXME, but this looks good

[AThousandShips]

There's a similar one in the servers test as well which fails as well:

godot/tests/servers/test_navigation_server_3d.h

Lines 767 to 783 in 4b7776e

	TEST_CASE("[NavigationServer3D] Server should be able to bake asynchronously") {
	NavigationServer3D *navigation_server = NavigationServer3D::get_singleton();
	Ref<NavigationMesh> navigation_mesh = memnew(NavigationMesh);
	Ref<NavigationMeshSourceGeometryData3D> source_geometry = memnew(NavigationMeshSourceGeometryData3D);
	Array arr;
	arr.resize(RS::ARRAY_MAX);
	BoxMesh::create_mesh_array(arr, Vector3(10.0, 0.001, 10.0));
	source_geometry->add_mesh_array(arr, Transform3D());
	// Race condition is present below, but baking should take many orders of magnitude
	// longer than basic checks on the main thread, so it's fine.
	navigation_server->bake_from_source_geometry_data_async(navigation_mesh, source_geometry, Callable());
	CHECK(navigation_server->is_baking_navigation_mesh(navigation_mesh));
	CHECK_EQ(navigation_mesh->get_polygon_count(), 0);
	CHECK_EQ(navigation_mesh->get_vertices().size(), 0);
	}

See:
https://github.com/godotengine/godot/actions/runs/8723662714/job/23932573763?pr=74830