Refactor the internals of antialiasing / backbuffer on WebGL device

[mvaligursky]

Before, the antialiasing was handled by requesting multi-sampled buffer from the context, and rendering to it. Browser's composer would later resolve this buffer to a single-sampled, and use it to render the web page.

The problem is that this approach took away the control of when the final resolve takes place from us, and even if part of the frame (post-effects for example) is single sampled, we still needed to write it back to multi-sampled surface, costing us a lot of memory bandwidth on tiled devices, which the composer needs to later resolve again for no reason at all, burning even more bandwidth.

This PR changes this, and we always obtain a single-sampled buffer from the context, which includes XR mode. We then allocate a multi-sampled framebuffer for it, and use the context's buffer as its resolve target.

This also unifies how this is done between WebGL and WebGPU, making further render pass modifications (incoming soon) a lot simpler / unified, and could allow further optimizations, for example only multi-sampling opaque rendering, then resolve, grab-pass color buffer, but stay on a single sampled-from then on.

Performance impact on Pixel 6 (GPU time):

• blend-trees-1d example: 4.6ms -> 4.2ms, so about 10% gain, related to postprocessing not having to be copied back to multisampled buffer.
• ground-fog example: 4.5ms->4.8ms. Many examples are now seemingly slower, just like this one. The reason as I understand is that we now measure the final resolve time as well, as it's done by us, instead of by the browser's composer later on. So even though the GPU time we report is larger, we just made this cost visible by our profiler, instead of hidden in the browser's use of the GPU.