FlxG.camera.bgColor isn't reset on state switch

[DetectiveBaldi]

I'm not sure if this is intentional, but it seems this getter for FlxG.cameras.bgColor is the cause.
When FlxG.cameras.reset is called when switching states, a new camera is created, but because of this getter, it ends up taking the bgColor from the last FlxG.camera.
I'm not sure why this getter exists, in my opinion it makes more sense for FlxG.cameras.bgColor to just be a setter that isn't automatically determined by the bgColor of FlxG.camera.
If there is a reason for this or if it is actually a bug, I would like to know. In my opinion it seems like strange behavior.

[Geokureli]

yeah this seems unintentional, but I do think this is kind of a breaking change, so I'm adding it to the 6.0.0 release, so we can add it to the migration guide

couple solutions:

1. Calling FlxG.cameras.reset will set the bgColor back to the default, by setting FlxG.camera = null; before creating the new cam
2. Somewhere in the state switching process before cameras are reset, FlxG.camera.bgColor is set to the default color, this means direct calls toFlxG.cameras.reset will not change the bgColor, but state switches will

I'm leaning towards 1

I also don't like the fact that CameraFrontEnd.bgColor's setter/getter reads/writes to/from cameras, and wouldn't mind if it was actually a variable, that camera's used when they have a null/uninitialized bgColor, but that seems like topic for another day, and would still require one of the solutions above

[DetectiveBaldi]

Yeah I understand merging something like this into 6.0.0. I honestly would vouch for removing the writing bgColor does to existing cameras in the same pull request, I think it's related enough.
Either way I can have a pull request fixing this issue in a couple hours.

[Geokureli]

Looks like "Closes: [issue number]" doesn't actually close them. In the future try, "Fixes", instead. i tried editing it but that didn't work because only happens when it's merged, I presume