[sunzenshen]

Bots steer for the landing once they fall past a drop

What it fixes

When a bot's path walks off a ledge (a drop-down), the path follower kept the top of the drop as the
bot's goal until its feet were within a step of the landing. Once the bot had walked off, that goal
was behind it, so the bot steered back toward the edge while it fell and landed moving backward,
then turned around again. On a run of ledges this reads as bots circling back after every drop.

The change

In PathFollower (NextBotPathFollow.cpp):

• IsAtGoal: a drop-down goal is reached once the bot is airborne and past the top of the drop,
  along the direction it approached the top from.
• Update: when that happens mid-air, the landing segment is skipped as well. It lies straight below
  the top of the drop, so it is just as much behind the bot; the bot heads for the next point on the
  path instead.
• Update, on touchdown: a bot that skipped the landing can come down on a ledge part way down the
  drop instead (a rim inside a shaft, say), where its goal is now below it and nothing acts until the
  stuck monitor fires about 5 s later. When it lands more than a step above the landing and more than
  a step below the top, its goal goes back to the top of the drop.

Nothing changes for a bot that has not walked off a drop, and it only acts on drops the path already
planned.

Testing

Debug build, headless bot matches, 12 bots.

• Test map with a corridor of 41 ledges to climb and drop off (1259 drops in 3 matches): drops that
  landed with the bot moving backward went from 62% to 4%; median walk-back after a drop from
  20-25 u to 0.
• One round on every ghost spawn of ntre_skyline_ctg, ntre_ballistrade_ctg and ntre_rise_ctg
  (21 matches), against the same sweep without the change: no asserts, fall deaths 6 -> 2, deaths in
  mid-jump 2 -> 0, stuck after a jump 24 -> 21, round outcomes unchanged.

With the touchdown restore added (Release for the test map, Debug for the matches):

• Test map, 5 matches, 2050 drops: 4.2% landed moving backward (as before the restore), no fall
  deaths; the restore never fired there, since every drop on that map lands on the landing.

• One round on every ghost spawn of ntre_oilstain_ctg (5) and ntre_ghost_ctg (10): no asserts,
  no fall deaths. The restore fired once, on a ledge under a drop on ntre_ghost_ctg's north side;
  the existing too-high check re-pathed the bot on the same tick, with no stuck event after.

• A vent drop on a copy of ntre_ghost_ctg with its older navmesh, replayed 216 times per arm
  (Release):

  	reached the bottom	came down on the rim	waited for the stuck monitor	time
  master	201	15	15	3.4-4.2 s
  Bots walk off a ledge they land on part way down a drop #2201 + Re-path a bot that stands above its path #2214	216	0	0	3.3-4.2 s
  this PR + Bots walk off a ledge they land on part way down a drop #2201 + Re-path a bot that stands above its path #2214	216	216	0	3.3-4.1 s
  this PR alone	0	216	0	-

  With the landing skipped, every bot in that narrow shaft comes down on the rim. Bots walk off a ledge they land on part way down a drop #2201 walks it off
  the rim on the touchdown tick, so the three together arrive as fast as Bots walk off a ledge they land on part way down a drop #2201 and Re-path a bot that stands above its path #2214 alone. On its
  own this PR hands the rim to the existing too-high check, which re-paths the bot away instead.

Merge order

This should merge after #2201, which handles a bot standing on a ledge part way down a drop; without
it, narrow shafts like the vent above get worse than master. Merging it next to #2214 gives a textual
conflict in PathFollower::Update: keep this PR's touchdown restore block first, then #2214's check.

[sunzenshen]

Jumplab map for testing:

dev_dbg_jumplab_vr_ctg.zip

Original behavior where bots move backwards that prompted this PR:

jumplab_vr_side.mp4