RGB(A)8 renderbuffers on WebGL 1.0

[lexaknyazev]

This looks like a quirk existing due to historical reasons but may still be worth clarifying.

1. WebGL 1.0, Section 2.2 guarantees that the default renderbuffer has at least 8 bits per component.
2. OpenGL ES 2.0, Section 4.4.3 allows only RGBA4/RGB5_A1/RGB565 internal formats for renderbuffer color attachments. 8-bit renderbuffers are provided only by OES_rgb8_rgba8.
3. WebGL EXT_sRGB extension is based on GL_EXT_sRGB that requires OES_rgb8_rgba8.

Given 1-3, it seems quite counter-intuitive that WebGL 1.0 renderbuffers can have SRGB8_ALPHA8_EXT or floating-point formats but not RGBA8.

At the very least, we should add a note to EXT_sRGB clarifying the ignored dependency. Optionally, WebGL 1.0 renderbuffers may be allowed to have RGB8/ RGBA8 internal formats (aliased as their unsized counterparts, similar to DEPTH_STENCIL) as if OES_rgb8_rgba8 is always enabled.

Maybe related: #3364.

/cc @kenrussell @kdashg

[kdashg]

The proper way to do this would have been to have OES_rgb8_rgba8 as an extension.
However, at one point, we agreed to require an FB with a RGBA/UNSIGNED_BYTE tex attachment as framebuffer-complete.
Probably we should functionally add OES_rgb8_rgba8 to core and add RGBA8 enum and allow it for renderbufferStorage.

I know this is a late-breaking change, but it would nicely close of this corner of issues. (and having RGB8 but not RGBA8 I'm sure always surprised people)

This would be feature-testable during roll-out because gl.RGBA8 will be undefined on browsers that haven't rolled this minor upgrade out.

FWIW, renderbuffers don't take gl.RGB, and require the sized RGB8 enum. DEPTH_STENCIL is an exception that we don't want to emulate here.

[kenrussell]

Discussed in WebGL conference call of 2022-08-11. There was consensus not to add an OES_rgb8_rgb8 extension. There was disagreement about whether to add the RGBA8 enum to the WebGL 1.0 spec, so this will not move forward (without a vote). At this point I personally think we should focus on WebGL 2.0 and not continue polishing WebGL 1.0 and its extensions. Adding an implementation note to the EXT_sRGB extension about this seems fine.