avm1: Improve behavior of Sound when loadSound() has been called

[ChrisCPI]

Description

Fixes #5019
Fixes #22572

This fixes several of the behaviors of the Sound object when playing external sound via loadSound().

Some of the key changes:

• When loadSound is called on a Sound, it appears that it enters a state of being "separated" from its original owner (even when controlling global sound). This means it can no longer control any prior sounds that were added to it via attachSound (and can no longer attach new sounds in this way), and it inherits its own unique sound transform, not attached to any particular display object. This has now been implemented.
• Added the ability to load sounds synchronously (where execution is paused until load has completed) when loading local sounds on desktop, matching the Flash Player behavior where methods like start() could become immediately available in this case.
  • Additionally, the playback queue has been removed, as this was an incorrect interpretation of the behavior that was just described.
• It appears that a single Sound object can only load one sound at a time. Trying to call loadSound() again while another sound is being loaded will cancel the load, and onLoad gets called with false given as the success parameter (See the avm1/sound_load_multiple_remote test).

Testing

Several tests added to cover this.

Checklist

• I, a human, have self-reviewed this PR and fully understand the changes within.
• I have made or updated tests where possible.
• All of my commits are properly scoped, compile successfully, and pass all tests.
• This PR does not make sense to split up into smaller PRs.
• An LLM was involved in the authoring of this code. (Used in authoring the added set_sound_transform_with_handle function, and the logic for the load IDs to prevent multiple loads at one time on a single Sound)

[Lord-McSweeney]

If both is_stopped and transform are only valid for external sounds, I would suggest adding a new struct called ExternalSound or ExternalSoundInfo that holds both pieces of information, and adding a single Option<ExternalSoundInfo> field to SoundData rather than the two new fields.

[ChrisCPI]

I can look into doing that if no one disagrees with the idea.

[ChrisCPI]

If both is_stopped and transform are only valid for external sounds, I would suggest adding a new struct called ExternalSound or ExternalSoundInfo that holds both pieces of information, and adding a single Option<ExternalSoundInfo> field to SoundData rather than the two new fields.

@kjarosh Thoughts on doing this idea? I think it could be helpful in using that to check whether the sound is external, rather than checking the transform.

[kjarosh]

It depends on how this plays with the loading state, if it's unrelated to the state then yes.

[ChrisCPI]

Putting this in draft for now - Need to do some refactoring, as it looks like the idea of the existence of a playback queue for loaded sounds is incorrect, and so I will likely remove it (effectively undoing most of #21163).

What actually appears to be happening is that in FP, local sounds are loaded synchronously, so that when loadSound() is called, it doesn't continue executing until the sound has been loaded. This is why the start() calls appeared to be queued, when they actually are not.

An easy way to observe this is to see that the onLoad listener can be fired in-between two traces before/after a loadSound() call. e.g.:

var s = new Sound();
s.onLoad = function() { trace("onLoad"); }
trace("before");
s.loadSound("sound.mp3");
trace("after");

In the local projector, this outputs:

before
onLoad
after

But when loading a remote file, it becomes asynchronous, and start() calls have no effect before the sound is fully loaded.

[Lord-McSweeney]

Thank you for working on this!