[Fix] (MG_Backend): read back the stencil half, and clear an sRGB target to the value asked for

Two reasons a framebuffer's contents came back wrong, both on the read/clear
side rather than the write side.

Stencil, on both backends. The CTS reads stencil with glReadPixels(GL_STENCIL_INDEX,
GL_INT), which is as legal as the unsigned widths, and neither backend accepted
it: DirectGLES's ReadPixelsStencilViaNative rejected every signed type, after
which the call fell through to a native ES read the driver refuses and nothing
was written at all, so the caller kept its zeros; DirectVulkan's pack switch had
no GL_INT case, and of the cases it did have only GL_UNSIGNED_INT sourced the
stencil plane - GL_FLOAT and GL_UNSIGNED_SHORT emitted a depth value, which is
meaningless for a stencil-only image. Both now take the signed and float widths,
and DirectVulkan decides "this is a stencil read" once rather than per type.
DirectGLES also gains the GL_FLOAT_32_UNSIGNED_INT_24_8_REV fallback a
DEPTH32F_STENCIL8 attachment needs, which rejects the 24_8 packed type.

sRGB, on DirectVulkan. Every other write path goes through the UNORM twin view
while GL_FRAMEBUFFER_SRGB is off, storing the raw value GL asked for, but a
deferred clear is materialised with vkCmdClearColorImage - which names the image,
so the driver applied the sRGB transfer function and a clear to 0.25 landed at
0.537. PreCompensateSrgbClearColor hands it the linear colour whose encoding is
the requested value instead. It is a no-op for non-sRGB destinations, for integer
clear encodings, and when GL_FRAMEBUFFER_SRGB is on and GL really does want the
encode.

Takes renderbuffers_storage from failing to passing on both backends, plus
renderbuffers_storage_multisample and framebuffers_blit on Espryt.

MobileGL/MG_Backend/DirectVulkan/Renderer/VkClearManager.h

@@ -50,6 +50,15 @@ namespace MobileGL::MG_Backend::DirectVulkan {
     // the destination is known.
     void ForceOpaqueClearAlpha(ClearAttachmentPayload& payload);
 
+    // vkCmdClearColorImage names the image, so the driver applies the destination format's transfer
+    // function to whatever value it is handed. Every other write path in this backend goes through
+    // the UNORM twin view while GL_FRAMEBUFFER_SRGB is off (ResolveSrgbAttachmentWriteFormat) and
+    // therefore stores the raw value GL asked for. Rewrites `payload` to the linear colour whose
+    // encoding is that raw value, so a direct image clear of an sRGB destination agrees with them.
+    // A no-op for every other format, for integer clear encodings, and when GL is doing the
+    // encoding itself.
+    void PreCompensateSrgbClearColor(ClearAttachmentPayload& payload, VkFormat destinationFormat);
+
     struct PendingClearKey {
         MG_State::GLState::ITextureObject* texture = nullptr;
         Uint64 textureLifetimeId = 0;