"change atan2_safe to atan2" followup

[Goober5000]

Follow-up to #6255. Partially restore use of atan2_safe from 87ea04f: keep special case while delegating most cases to atan2.

Fixes #7530.

[Baezon]

Sigh... any negative 0 in either argument of atan2 results in ±pi, which means floating point inaccuracy and instability, especially around poles. This isn't really "safety", if you want to be pedantic about the naming, more than it is guaranteeing the result is +0 which will stay stable.

[MoerasGrizzly]

layman question: Why use atan2 at all rather then the original volition function? What's the performance vs inaccuracy trade-off being made here?

[Goober5000]

layman question: Why use atan2 at all rather then the original volition function? What's the performance vs inaccuracy trade-off being made here?

The primary reason is for the special case at 0, 0. See the comment on the previous PR:

According to DahBlount:

Most atan2 implementations for a long time had problems when the inputs were close to machine epsilon or when x was less than or equal to 0

And according to z64555:

Modern versions of C++ should have an atan2() that works correctly when the inputs are at 0 or near epsilon of the floating point specification, meaning Volition's workaround shouldn't be needed anymore.

So this removes atan2_safe and changes all instances to atan2. Consequently, the angle range in FRED now shows as [-180, 180] as expected.

In most respects the library function is to be preferred over the hand-rolled function, so changing to atan2 was a good idea for the general case. But for the special case of 0, 0, this devolves into gimbal lock, which will cause the viewpoint to flip 180 degrees as you noticed. So all this is really doing is adding back handling for the special case.