Make cubic_interpolate() consider key time in animation

[TokageItLab]

Fixes #60154.

In the previous implementation, cubic_interpolate() did not consider time, resulting in clunky transitions when the key interval was not constant. The following images show animations with the same keyframes, but the left one is the previous cubic_interpolate() without time(velocity) consideration and the right one is this PR with time(velocity) consideration.

By providing time as an argument, it allows for smoother movements. Also, based on previous implementations, the default values of the argument are -1.0, 0.0, 1.0, 2.0. The result of this argument will be the same as the previous implementation, but if there are performance concerns in Curve or Gradient classes, it may want to separate the functions.

1_5_1.mp4

1_6_1.mp4

If anyone don't want overshoot, simply adding more plots will solve the problem, but if the demand is too much, we can consider implementing makima interpolate (#57952) or adding a function to AnimationTrack that switches between the previous implementation and the new one.

[fire]

The previous problems with non default arguments have been resolved. Approved.

We are not solving overshooting here.

[reduz]

I would not replace the existing function to be honest, since you don't always need to use it in time and this is more costly and complex.
I would add a new function cubic_interpolate_in_time() instead, which IMO makes more sense.

[TokageItLab]

Ok, I'll modify this PR later.

[TokageItLab]

@reduz Changed this PR implementation to add cubic_interpolate_in_time() as a new interpolation type.

[akien-mga]

Thanks!