Fix closest possible navigation path position

[smix8]

Fixes closest possible navigation path position.

Fixes #78943.

This fixes two edge cases in the navigation mesh pathfinding related to unreachable target positions. It wouldn't affect pathfinding when the target position is reachable.

In the situation of an unreachable target position the users expect a path returned that goes from the closest point to the start position to the closest possible point reachable to the target position.

Without the fixes in this pr the path would in certain cases be either empty or end at the wrong position on an unexpected polygon.

The first edge case was that an empty path is returned as the fallback when no route is found at all. This is the case when the starting polygon has not a single connected edge, e.g. is a single, isolated triangle or other convex polygon. Since the pathfinding loop goes through connections it does not run to the code point where it would add path segments for a basic route, returning the empty path as the defined fallback. Now in this case an additional search of the start polygon faces is added.

The second edge case was if the target position is on an unreachable polygon and the start polygon happens to be the one with the closest possible position to the target position, it would still pick positions on other polygons. The reason for this is that the first polygon is never fully added to the path corridor, only the segment from the start position to the first connected edge is added. This means the start polygons entire faces are not considered in the search for the closest, possible position to the target. Only position along the line segment from start position to edge are. If another polygon would have a point closer than this segment the path would use the other polygon instead even if visually the user would see the start polygon being closer. Now in this case a full search of the start polygon faces is added.

[smix8]

I tested a few scenarios that I could think of with Godot Engine v4.2.dev.mono.custom_build.28e251c5c and it seems like everything works as expected.

I think we can merge this earlier in the 4.2 cycle so we have enough time before it gets a potential cherry-pick for older Godot4 versions. I don't expect much in terms of regressions because the PR only does something in "if" branches that already have no path to the target. As quoted razcore also tested it extensively and reported that it works as expected and fixes the issues.

[akien-mga]

Thanks!

[YuriSizov]

Cherry-picked for 4.1.1.