Implement modular and more explicit render passes

[mvaligursky]

Currently, the PlayCanvas engine does not implement explicit render passes (rendering processes with outputs going to different render targets), and rendering is driven directly by ForwardRenderer, making it pretty complex and harder to extend. This includes rendering of the main scene, depth and color grab passes, shadow maps, shadow and cookie atlases and multiple post-processing effects and similar.

We're facing multiple issues with this system currently:

• WebGPU requires the rendering to be submitted using render passes, to allow optimal performance on tiled architectures, in relation to load and store operations on the render attachments.
• WebGL can benefit from similar organisation, and use invalidateFramebuffer to save considerable memory bandwidth on tiled architectures.
• Without clear understanding of render passes, the management of resolves of multisampled attachments as well as mipmap generation (specifically for cube maps) becomes complicated, and we are wasting a lot of performance performing those when not needed.

We've identified a solution to improve this, which is the FrameGraph. It allows the frame rendering to be described in a graph form, where the nodes represent render passes (rendering into a render target). Edges represent dependencies of those render targets. This will allow us to solve the mentioned issues, and implement more flexible and performant rendering architecture.

References:
https://developer.mozilla.org/en-US/docs/Web/API/WebGL2RenderingContext/invalidateFramebuffer
https://www.gdcvault.com/play/1024612/FrameGraph-Extensible-Rendering-Architecture-in
https://www.dropbox.com/s/89pvx9obhv6m0pk/High%20Quality,%20High%20Performance%20Graphics%20in%20Filament%20(Handout).pdf?dl=0

[Adriaaaaan]

I'd just like to say, I think its awesome you're working on these kinds of tasks. Its so easy nowadays to focus on visual flashy features but its the architecture work that really helps to deliver them in a practical, maintainable and performant manner.

[mvaligursky]

I'll close this, as on a generic level this has been done already, and will open separate issues on further work in this area.

[mvaligursky]

Related: #5686