Allow negative speed_scale in AnimatedSprite2D & 3D

[Mickeon]

This PR unlocks AnimatedSprite2D and AnimatedSprite3D's speed_scale, allowing it to go below 0.
If the speed_scale is set to a negative value, the animation plays backwards.
The second parameter of play(), backwards, works as before. If set to true, and speed_scale is negative, the animation plays forward. As such, this is barely if not a compatibility-breaking change, unless users were relying on the previous clamping.

It also slightly tweaks the internal code, as a follow-up from #64155.
I may do something more drastic later on, because the internals of this class look somewhat archaic, and there actually are some bugs and odd inconsistencies only some users like me may notice.

May need some testing regarding signal emissions.

Note: Having a method returning (speed_scale < 0.0) may still be beneficial for less math-leaning users and for readability purposes, but I'm not sure. Perhaps too situational.

The second parameter of play(), backwards, now reverses the current speed_scale when necessary.
This is no longer the case. The speed_scale Because of it, the true "direction" still cannot be known.
Closes godotengine/godot-proposals#5286 (see comments).
Closes godotengine/godot-proposals#4506.
Supersedes #41821.

[Mickeon]

@Calinou Upon reevaluation, I have to unfortunately say that this is at least slightly compatibility breaking, even if welcome. Thinking of situations where the scale of an animation's speed changes dynamically (e.g. running animation dependent on speed), where it is constantly set to a certain positive value, which means that unlike the previous behaviour, if the animation is by chance also reversed, it would snap back to not being so upon setting the property.

Edit: accidentally closed.

[TokageItLab]

I don't know if it should finish when animation reach first frame with speed_scale is negative in the case where there is no loop and backward == false.
FYI, in AnimationTree it will not be finish, but in AnimationPlayer it probably will be finish.

[dalexeev]

@Mickeon Sorry, I inadvertently implemented the same changes as you in a larger PR. I haven't looked at your PRs. For example, I fixed the processing logic differently (and more compactly).

[Mickeon]

It doesn't necessarily supersede it, but because both this and the mentioned PR are contested changes, it would be better to implement one thing at the time, then rebase if necessary.

[Mickeon]

This PR has been rebased and it now applies to AnimatedSprite3D as well, now that it can, since #64155.

[kleonc]

I don't know if it should finish when animation reach first frame with speed_scale is negative in the case where there is no loop and backward == false.

@TokageItLab I think this implementation doesn't allow such situation, speed_scale < 0 if and only if backwards == true. It's ensured in the set_speed_scale/play methods.

[dalexeev]

Sorry if I sound rude or arrogant, but in #65609 these issues are already resolved, these PRs overlap quite a lot. Things that are in this PR but not in #65609 are general edits like !frames.is_valid() -> frames.is_null(). I'm not opposed to this PR being merged, it just doesn't seem to make much sense to me. My patch size won't decrease much even if this PR gets merged.

[kleonc]

Checked the code, LGTM (and I do like the feature).

[kleonc]

Sorry if I sound rude or arrogant, but in #65609 these issues are already resolved, these PRs overlap quite a lot. Things that are in this PR but not in #65609 are general edits like !frames.is_valid() -> frames.is_null(). I'm not opposed to this PR being merged, it just doesn't seem to make much sense to me. My patch size won't decrease much even if this PR gets merged.

@dalexeev Personally I prefer few separate small PRs over a single all-in-one PR. It's just simpler to review such changes / harder to miss something. It's not like the features in your PR rely on each other, they can be introduced separately. I'm not suggesting it just for the sake of separating things. One feature might be welcomed but the other might be unwanted for whatever reason. Separating things makes it easier to discuss/approve specific parts (in some cases it might actually fasten the whole process).
And of course part of your PR is already made in here so it's kinda a partially duplicate. But I do like the "Add support for individual frame duration to SpriteFrames." part, just haven't looked at it properly yet.

[Mickeon]

At this point do you think it would be a bad idea to remove the second parameter of play(), add play_backwards() and have both do and document the sign inversion on speed_scale when necessary?

I mean, see if something else is off in this PR, then it can be merged and I can see later on. A Proposal would be very appropriate for this discussion.

[kleonc]

Mainly typos.

[Mickeon]

Removed every "frame check" early return during iteration because frame is always clamped appropriately to at least be above 0.

[Mickeon]

I know I am the only person on Earth interested on this Node, and I do really really love to improve on it, but it'd be a good idea to merge this one and seeing how to go from there. I implied it before, but I would like to make a bunch of PRs about it

[TokageItLab]

LGTM, thanks for nice job!

[akien-mga]

Thanks!