Fix background bleeding through

[Pheubel]

This resolves #1831

In order to fix this issue i implemented it as described in #1826 (comment)

I had to change a few things:

• The structure of the default default dialog node scene has changed a little bit, I added two nodes in the background holder, a node that contains all the backgrounds that get swapped in. And a color rect called Overlay that uses the backgrounds to draw the actual background that needs to be displayed.
• The default background scene has changed a little bit, instead of a color rect with a texture rect child, i have a parent SubViewportContainer with a viewport as child. The overlay relies on the viewport to get a texture of what is happening in the scene to the overlay. The texture provided by the viewport is actually dynamic, so any changes that happen inside the viewport do get drawn, so animated scenes as backgrounds should work just fine.
• The code for the background submodule has been changed a bit, the role of _fade_in(float) and _fade_out(float) have been reduced to notifications that the background scene is fading in/out, i think this is the best fit for them, as the transition.
• I added a whipe transition shader and material, this is what powers the overlay, it transitions between the previous and next background. For now, the feather and whipe texture have been set in the material, to 1 and a midtone gray respectively. This paves the road for possible custom transitions using whipe textures.

Breaking changes:

• existing custom background scenes will most certainly break, as they do not return a ViewportTexture. In order to fix them, their scene structure has to be changed to have a SubViewportContainer as root with a SubViewPort as child, they can then put everything they had as child of the SubViewPort. Afterwards they need to make sure that the node references are all wired up correctly.
• Custom transitions in _fade_in(float) and _fade_out(float) will likely behave in an unexpected way, i didn't have a use case to test how they would behave.

What this allows for in the future:

• Custom transitions using self made textures (easy for developers) - The mechansim implemented for the transitions here makes use of a whipe texture with a feather already, the code needs to be altered in such a way that it keeps the current settings as a default if no whipe texture is provided. There might also need to be an option to indicate how the whipe texture should be applied (toggle between stretch to rect VS scaled to keep the aspect ratio) I don't think it would be a hard task, but requires a bit of UI design.

• Custom transitions using custom shaders (harder for developers) - The shader would have to have a material replace the material in the overlay material, this would require a bit more thought, it will essentially be like the texture transitions, but will require some more code to make sure that the properties are set right. It will require a bit more UI work in order to get this to work well. I would imagine that if this were to be added, it will need to make use of the Key Value pair element that i made for Allow for signal events to optionally pass dictionaries instead of strings #1829, but more advanced to allow for data types outside strings. I think this feature is possible, but definitely an advanced feature.

[Jowan-Spooner]

Note to future visitors: The implementation of this has changed quite a bit.

[Jowan-Spooner]

@Pheubel Thanks for all the work and patience!