Make AnimatedSprite2D update animation property when SpriteFrames changes

[L4Vo5]

AnimatedSprite2D will ensure it has a valid animation when the SpriteFrames is set, and on its "changed" signal.
To that end, makes SpriteFrames emit the "changed" signal when one or all of its animations are deleted.
Note that the animation property will remain as-is if the SpriteFrames has no animations at all.

Removes error message on set_animation when SpriteFrames is null, which caused "no animation with name X" errors even with the "default" value of freshly created instances.
So, this allows the animation property to be set even without a valid SpriteFrames. And once one is added, the animation will be changed if necessary to make it valid, making the error pointless.

Fixes #45459 and #28658.
Related to #49495 on the 3.x branch.

[L4Vo5]

Changed the files according to the suggestions
on _res_changed(), I put the second set_frame on an else block. After all, set_animation shouldn't quit early, and it'll call set_frame(0); itself

[kleonc]

@L4Vo5 Changes made in AnimatedSprite2D would need to be done in AnimatedSprite3D too.

Also as you can see static checks fail (formatting issues), you'd need to apply clang-format to fix these. I recommend adding relevant pre-commit hooks to run it automatically when you commit (so you can fix formatting issues immediately).

[kleonc]

HashMap::erase returns a bool telling whether the erasing happened.

Suggested change

	animations.erase(p_anim);
	emit_changed();
	if (animations.erase(p_anim)) {
	emit_changed();
	}

[kleonc]

@akien-mga This returns sorted animation names, as desired (so its first element is indeed what we want):

godot/scene/resources/sprite_frames.cpp

Lines 105 to 112 in 9904a9d

	Vector<String> SpriteFrames::get_animation_names() const {
	Vector<String> names;
	for (const KeyValue<StringName, Anim> &E : animations) {
	names.push_back(E.key);
	}
	names.sort();
	return names;
	}

But in other places in the source code SpriteFrames::get_animation_list() is being used instead and the obtained list is being sorted separately:

godot/scene/resources/sprite_frames.cpp

Lines 99 to 103 in 9904a9d

	void SpriteFrames::get_animation_list(List<StringName> *r_animations) const {
	for (const KeyValue<StringName, Anim> &E : animations) {
	r_animations->push_back(E.key);
	}
	}

godot/editor/plugins/sprite_frames_editor_plugin.cpp

Lines 985 to 987 in 9904a9d

	List<StringName> anim_names;
	frames->get_animation_list(&anim_names);
	anim_names.sort_custom<StringName::AlphCompare>();

Both approaches seem to result in the same ordering (both end up comparing with is_str_less). But I think we should be consistent and use one over the other. I'd guess sorting a list is probably slower (it probably doesn't matter though) but in the list version there's no StringName -> String conversion (which is also cheap I guess). So is any of these approaches preferred?

[L4Vo5]

Thanks for the clang help!

Changes made in AnimatedSprite2D would need to be done in AnimatedSprite3D too.

Should that be a separate PR?
I've been looking at the code, and there's a few other differences AnimatedSprite3D has compared with 2D. For example: it can't play backwards, it doesn't support speed scale, and it produces no errors on invalid animations.
That last one would make sense to change if I add AnimatedSprite3D to this PR, but since there's more important differences anyways, I think a separate PR to bring the missing features to AnimatedSprite3D would be better. I can get started on that, and if anything just bring the code to this one.

[L4Vo5]

Applied changes to AnimatedSprite3D following #64155, which brought the same errors to it (but also made it infinitely easier to make the same changes)

[KoBeWi]

AnimatedSprite underwent many changes recently and both issues are now closed. Is this PR still relevant?

[L4Vo5]

Hmm, the current fix for 28658 is only in the inspector: it does nothing when deleting animations in code. Still, that makes the issue even more minor than it was before, so this PR is probably not worth keeping as it'd require a full revision to update it just for that.