[math] Add SmoothStep and SmootherStep easing functions

[scottmcm]

Objective

Almost all of the *InOut easing functions are not actually smooth (SineInOut is the one exception).

Because they're defined piecewise, they jump from accelerating upwards to accelerating downwards, causing infinite jerk at t=½.

Solution

This PR adds the well-known smoothstep, as well as its higher-degree version smootherstep, as easing functions.

Mathematically, these are the classic Hermite interpolation results:

• for smoothstep, the cubic with velocity zero at both ends
• for smootherstep, the quintic with velocity zero and acceleration zero at both ends

And because they're simple polynomials, there's no branching and thus they don't have the acceleration jump in the middle.

I also added some more information and cross-linking to the documentation for these and some of the other easing functions, to help clarify why one might want to use these over other existing ones. In particular, I suspect that if people are willing to pay for a quintic they might prefer SmootherStep to QuinticInOut.

For consistency with how everything else has triples, I added Smooth(er)Step{In,Out} as well, in case people want to run the In and Out versions separately for some reason. Qualitatively they're not hugely different from Quadratic{In,Out} or Cubic{In,Out}, though, so could be removed if you'd rather. They're low cost to keep, though, and convenient for testing.

Testing

These are simple polynomials, so their coefficients can be read directly from the Horner's method implementation and compared to the reference materials. The tests from #16910 were updated to also test these 6 new easing functions, ensuring basic behaviour, plus one was updated to better check that the InOut versions of things match their rescaled In and Out versions.

Even small changes like

-    (((2.5 + (-1.875 + 0.375*t) * t) * t) * t) * t
+    (((2.5 + (-1.85 + 0.375*t) * t) * t) * t) * t

are caught by multiple tests this way.

If you want to confirm them visually, here are the 6 new ones graphed: https://www.desmos.com/calculator/2d3ofujhry

---

Migration Guide

This version of bevy marks EaseFunction as #[non_exhaustive] to that future changes to add more easing functions will be non-breaking. If you were exhaustively matching that enum -- which you probably weren't -- you'll need to add a catch-all (_ =>) arm to cover unknown easing functions.

[scottmcm]

Given that adding something to an enum is technically a breaking change, I figured I'd do the broader breaking change of marking this #[non_exhaustive] so that any future additions to the enum will be non-breaking.