Add advance_on_start option to NodeAnimation to handle advance(0) for each NodeAnimation

[TokageItLab]

• Closes StateMachine has delay which is caused by transition from Start to the first state needs one frame #91215
• Prerequisite Fix StateMachine process when transition to end & optimize StringName #94304

As described in the AnimationPlayer documentation, the default behavior is for the animation to draw the first frame immediately after playback.

[b]Note:[/b] The animation will be updated the next time the [AnimationPlayer] is processed. If other variables are updated at the same time this is called, they may be updated too early. To perform the update immediately, call [code]advance(0)[/code].

While this may be desirable for managing very different states, this behavior may cause a hitch if you want to handle a sequence of animations.

This PR can be modified to properly pass delta at start time, and an option can be added to apply the same advance(0) behavior at start time to each NodeAnimation.

This option must be had for each NodeAnimation, not for the entire AnimationTree since we need to be able to handle many cases, for example, the first state in a StateMachine may want to disable it and the others may want to enable it. Also, this can only be added to the lowest level - NodeAnimation, for the same reason as custom_timeline, given the possibility of it being broken by nesting.

However, the hitch is not yet completely eliminated; there may still be a small amount of error due to a decimal point error when comparing double values. The get_remain() function for the remaining time has been improved a little by setting the double value to zero by approximation. But to solve this problem completely, I think it is necessary to change all AnimationNode time comparisons to compare approximate values that take the error into account.

Most of the problems have been eliminated, but in cases such as 1 animation vs. 3 animation queues, there is a possibility that the animation may not be perfectly synchronized due to a small error in the decimal point from the "animation length". Well, the results seem to be relatively stable as long as CallbackModePhysics is used.

[SaracenOne]

Discussed and tested at Animation Meeting and seems to be a satisfactory fix to the issue rasied 👍

[Repiteo]

Thanks!