Fix potential game freeze from infinite while-loop in GetGroundHeight

[treacherousfiend]

Description

This PR fixes a potential infinite loop in CNavMesh::GetGroundHeight() by adding an early out if the position input is NaN.

The place that I noticed this being an issue is the TF2 Sentry Buster's mission behavior, which will input a vector of all NaNs if it doesn't have a mission target set.
I don't believe this can happen under normal circumstances currently, but if the SetMission() vscript function gets fixed then users who forget or simply don't know that they need to set a mission target first will find that their game will freeze, not crash, due to it getting stuck attempting to trace a line to the ground from NaN to NaN over and over again.

Technically superseded by #972, which fixes the bug in the sentry buster code rather than the NavMesh code
This probably could be fixed within the Sentry Buster's behavior too (CTFBotMissionSuicideBomber::Update(), specifically the line if ( m_path.Compute( me, m_lastKnownVictimPosition, cost ) == false )), especially since if a the path compute check fails 3 times the Sentry Buster starts its detonation, but I decided to go for the change in the NavMesh code in case other parts of the code may cause the same issue when used via vscript or sourcemods in ways not originally intended by the developers over a decade ago.

[A1exKH]

LGTM.

[ficool2]

You should identify and fix the root cause of the issue, it makes no sense to put a NaN check here when the cause is likely an uninitialized variable somewhere.

[treacherousfiend]

You should identify and fix the root cause of the issue, it makes no sense to put a NaN check here when the cause is likely an uninitialized variable somewhere.

I thought I went over that in the issue post, but I guess I forgot to last night. In the case of the sentry buster its mission target is set by the mission populator when it spawns the sentry buster, so if its not given the mission via the populator, the mission target is not set.

I was concerned that there may be several other instances aside from just this in which a commonly used function like GetGroundHeight would be passed invalid inputs, enough so that fixing it within that function was more worthwhile than attempting to patch up the NaNs as they come up.
Although today I've now looked through about as many calls to it as I reasonably can in a shortish amount of time (presuming VS actually shows me them, which it sometimes did not want to), and the only instance I could find where this issue could happen was, in fact, the sentry buster code. Everything else I looked at made sure that the variables it used were valid before sending them as an input.

I'm still a bit hesitant to just assume that everywhere else in the code simply does this correctly, especially now that vscript is a potential factor.
Additionally, the fact that there is a "fast" version of the function titled GetSimpleGroundHeight right below this function, and that the way this function is used the most via GetNearestNavArea has a comment right above the call which says "ensure source position is well behaved" I think implies that the "slower" version should potentially also be safer.

Regardless, I'll open up a PR soon which fixes this issue in the sentry buster code, and at that point people can pick and choose which fix they'd prefer for their projects.