Prevent a requirement for `@:privateAccess`-ing the _customSoundTray object.

[saturn-volv]

...And also allowing for it to be changed at runtime.

Access

Before, to change the sound tray, you would have to access the variable as such:

var game:FlxGame;

//...

@:privateAccess(flixel.FlxGame)
game._customSoundTray = CustomSoundTray;

And your access would have to be called before the game was created.

Now, you can change the sound tray at any time, through the method of:

FlxG.game.changeSoundTray(CustomSoundTray);

Now as long as your CustomSoundTray was a child of flixel.system.ui.soundFlxSoundTray, it would work.

[DetectiveBaldi]

i would say it would be better to deprecate _customSoundTray, make a new public variable (customSoundTray), and then make _customSoundTray a getter / setter for it. having a function to change one line feels a bit redundant

[Geokureli]

I think the idea here is to extend FlxGame with a class that sets these custom classes before calling super.create()

I'm open to reconsider these custom classes, but I'd rather just come up with a plan for all of them, first.

another option is to define FLX_NO_SOUND_TRAY and just make your own in-game sound tray

[saturn-volv]

ahh I've got you now. yeah extending FlxGame seems like a much better idea rather than adding all this. But yeah coming back to it in the future is definitely a good idea, I'll look more into a design for it and come back to this PR then.

[Geokureli]

We discuss this further at #3107, I think adding a setter here is a bad pattern, also this change would remove the need for @:privateAccess, since the stuff you added is all private