Trajectoryheight HaveFreeLineOfFire fix

[KyleAnthonyShepherd]

trajectoryheight missiles have been using a quadratic trajectory assumption for HaveFreeLineOfFire checks.
However, this assumption was poor for missiles with acceleration, and was poor for firing at different elevations.
This causes multiple false positives, blocking fire in some cases
#869
Or false negatives, causing friendly fire or firing missiles into cliff faces requiring game-side workarounds
beyond-all-reason/Beyond-All-Reason#1796

This PR acknowledges that trajectoryheight missiles follow a Pursuit curve path, and uses a simple numerical ordinary differential equation (ODE) solver method (Heun's method) to obtain the approximate path.
[Other methods, such as trying to fit the trajectoryheight missile curve to a cubic equation, were tried and did not work]

This has been performance tested, with wallclock time, to ensure no negative performance impact.
BAR corban firing at max range, with 1 friendly unit under the trajectory.
Base engine, 0.53 seconds to perform 100,000 HaveFreeLineOfFire checks.
With PR, 0.51 seconds to perform 100,000 HaveFreeLineOfFire checks.

[KyleAnthonyShepherd]

Leaving a note here for myself.
This fix, which allows firing at higher elevations, is revealing that trajectoryheight missile units (BAR corcat) with high wobble and high dance values sometimes causes missiles to just careen straight downward.
May require MissileProjectile.cpp to be tweaked.

[KyleAnthonyShepherd]

Tweaked MissileProjectile.cpp so zero turnrate, high wobble units (like the BAR corcat) have expected behavior when aiming at high elevations (now that it is no longer blocked by false positive ground collision checks).
The tweak should only apply when

1. The missile is currently pointing below the target
2. The missile elevation is currently below the target

So all other trajectoryheight missile behaviors should be unaffected.

[KyleAnthonyShepherd]

Looked over this PR again, with a fresh view. It still looks good to me. Squashing and merging.