### Godot version

4.0-dev (master)

### System information

Win 11

### Issue description

Reported by @ExquisiterEmil on Discord

I analyzed an issue regarding the animation player - it keeps behaving weirdly when using an AudioStreamPlayer and using the AnimationPlayer. After adding a couple of debug messages and following various weird calls (up to 5 calls to animation process during _stop_internal) I narrowed the issue down to the following use-case:
- You have an AnimationPlayer
- You have an AudioStreamPlayer within the AnimationPlayer
- You position yourself somewhere "non position 0" in the timeline of the animation player (i.e. 'seek')
- You try to stop the animation player by pressing the "Stop" symbol (+ it shouldnt be playing in the first place because you haven't pressed 'Play' yet)
- The audio keeps playing but the bar resets to 0
- You press "Stop" again and it stops the audio.

From what I was able to analyze, the following process happens:
- When you click within the animation player, you trigger a _timeline_changed signal, this is being consumed by the AnimationPlayerEditor's "Seek Value changed" function, which in turn "stops" the player, seeks the position, and "starts" the player again. (See animation_player_editor_plugin.cpp:1169 -> animation_player.cpp:1984) -> Assumtion Nr. 1
![image](https://user-images.githubusercontent.com/761911/213870376-dd12d973-4e1e-483e-a24a-09e19c01a390.png)
- During the press of "Stop" you basically setting the seek value back to "0", and since this is another change of the seek valuje, it triggers another round-trip of seeking and pausing and unpausing the audioplayer.
![image](https://user-images.githubusercontent.com/761911/213870551-95d79a05-5bc3-4597-886a-ada6cca3c0c8.png)
- If you press once again, since the seek position is now "0", the round trip isn't triggered, and the animation processing isn't started, hence the audio doesn't start playing again. -> Assumtion Nr. 2

Assumtion Nr. 1:
- animation_player.cpp _stop_internal doesn't reset "is_stopping" to the proper previous state and just overrides it with "false" upon finish seeking (albeit setting "playing" to false)

Assumtion Nr. 2:
- I assume this behaviour like this, due to observing the stack trace of the calls, which only tripped my breakpoint once, here over at _stop_internal
![image](https://user-images.githubusercontent.com/761911/213870612-dfcfbe2c-c64d-41d4-ad4f-fe1e5ef6e927.png)
This, in turn, means that `frame->set_value(0);` does not trigger a seek again, which makes the audio player shut up.

Sadly, I have no idea how we could fix this, maybe instead of checking against the `if (!nc->node || is_stopping) {` block, we may also add a `|| !playing`? But maybe we are too early for this to trigger - someone with more experience in the animationplayer may be able to help out here.

If I should add anything to my analysis, let me know and I'll try to give more insight!


### Steps to reproduce

Listed above, download example project, open, click AnimationPlayer, seek somewhere, try to stop, ...

### Minimal reproduction project

[AudioPlaybackTrackIssue.zip](https://github.com/godotengine/godot/files/10472323/AudioPlaybackTrackIssue.zip)

if (p_anim == "[stop]" || p_anim.is_empty()) {
		stop();
	} else if (!is_playing() || playback.assigned != p_anim) {
		play(p_anim);
	} else {
		
	}
}
String AnimationPlayer::get_current_animation() const {
	return (is_playing() ? playback.assigned : "");
}
void AnimationPlayer::set_assigned_animation(const String &p_anim) {
	if (is_playing()) {
		play(p_anim);
	} else {
		ERR_FAIL_COND_MSG(!animation_set.has(p_anim), vformat("Animation not found: %s.", p_anim));
		playback.current.pos = 0;
		playback.current.from = &animation_set[p_anim];
		playback.assigned = p_anim;
	}
}
String AnimationPlayer::get_assigned_animation() const {
	return playback.assigned;
}
void AnimationPlayer::pause() {
	_stop_internal(false, false);
}
void AnimationPlayer::stop(bool p_keep_state) {