[Feat] (MG_Backend, MG_Impl, MG_Util): attach one layer of any layered texture on DirectVulkan

Whether a backend can attach a single layer of a texture to a framebuffer was one
Bool, so it could only give the most conservative answer any target needed.
DirectVulkan therefore declined every layer of every target and
direct_state_access.framebuffers_texture_layer_attachment failed with 542
messages across four targets.

The three ways a GL layer maps onto Vulkan are independent capabilities, so the
flag becomes a per-TextureTarget mask. A 2D or 2D multisample array layer IS a
VkImage array layer and needed nothing but the gate opened. A cube map array is
one 2D image with arrayLayers = 6 * cubeCount and CUBE_COMPATIBLE, which is a
shape VkTextureManager simply did not have - it is declined softly when the depth
is not a whole number of cubes or the level is not square, because that function's
Bool return exists for unrepresentable shapes and asserting there would abort on
ordinary input, GL_PROXY_TEXTURE_CUBE_MAP_ARRAY above all. A 3D texture's layer is
a z slice, which needs a 2D-array-compatible image and a per-slice clear, because
vkCmdClearColorImage cannot address a subset of a 3D image's slices - a render
pass whose only content is its LOAD_OP_CLEAR can, since its attachment is a 2D
view over that one slice.

VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT is asked for per format and withdrawn per
format, mirroring the MUTABLE_FORMAT pattern already in this file: the capability
is per format+usage, so a single global probe answers a different question than
the one the frontend goes on to ask. Losing it costs per-slice attachment for that
format; failing creation would lose the texture.

Three things found on the way that are not the headline:

glFramebufferTextureLayer, the non-DSA twin, had no gate at all and additionally
refused cube map arrays that GL 4.5 requires it to accept. GL 4.6 core 9.2.8 makes
the two entry points equivalent, so they now decline in the same places - leaving
one ungated is what let an unrepresentable attachment reach the renderer.

ComputeFullMipLevelCount takes max(x, y, z), and for every array shape z is the
layer count rather than a mip-able axis, so a 4x4 array with 192 layers asked for
six mip levels on an image whose legal maximum is three
(VUID-VkImageCreateInfo-mipLevels-00958). Only the image's own extent can bound
it. lavapipe had been letting that through.

A layered GL clear queues layerCount = depth, which is illegal for a
VK_IMAGE_TYPE_3D image (VUID-vkCmdClearColorImage-baseArrayLayer-01472 pins it to
0/1, read as the whole mip level) and the old code passed it straight through.

Takes framebuffers_texture_layer_attachment green on DirectVulkan, so the whole
direct_state_access suite is 371/371 there; Espryt stays 370/371, the remaining
case being the fp64 one it declines by design.

Known and deliberately not fixed here, with a FIXME at the site:
KHR-GL44/45/46.geometry_shader.layered_framebuffer.clear_call_support now fails on
DirectVulkan - a layered clear of a 3D texture reads back zeros. Those cases exist
only in the GL44+ lists, above the 4.0 this backend reports. An A/B of a 6935-case
subset (cube map array, texture storage, framebuffer, 3D, the full DSA suite and
the GL33 texture group) is otherwise clean on both backends: 16 cases fixed and
none broken on Espryt, 15 fixed and those 2 broken on Magma, and zero difference
anywhere at GL 4.0 or below. The FIXME records which causes were already ruled out
by bisection so the next reader does not repeat them.

MobileGL/MG_Backend/DirectGLES/BackendObject_DirectGLES.cpp

@@ -1112,8 +1112,24 @@ namespace MobileGL::MG_Backend::DirectGLES {
         // SyncAttachmentObject routes a layered upload target to glFramebufferTextureLayer with the
         // attachment's layer passed through, so this backend really does render to the layer it was
         // given - provided the driver resolved the entry point at all.
-        m_dynamicParameters.SupportsPerLayerFramebufferAttachment =
-            DirectGLES::g_GLESFuncs.glFramebufferTextureLayer != nullptr;
+        // SyncAttachmentObject (Managers.cpp, the glFramebufferTextureLayer branch) routes exactly
+        // five upload targets to glFramebufferTextureLayer with the attachment's layer passed
+        // through, so this backend really does render to the layer it was given - provided the driver
+        // resolved the entry point at all. The cube map array is the one target that also needs
+        // ES-level support before it has any storage to attach.
+        m_dynamicParameters.PerLayerFramebufferAttachmentTargets = 0;
+        if (DirectGLES::g_GLESFuncs.glFramebufferTextureLayer != nullptr) {
+            using DynParams = MG_Backend::DynamicBackendParameters;
+            m_dynamicParameters.PerLayerFramebufferAttachmentTargets |=
+                DynParams::PerLayerFramebufferAttachmentBit(TextureTarget::Texture3D) |
+                DynParams::PerLayerFramebufferAttachmentBit(TextureTarget::Texture1DArray) |
+                DynParams::PerLayerFramebufferAttachmentBit(TextureTarget::Texture2DArray) |
+                DynParams::PerLayerFramebufferAttachmentBit(TextureTarget::Texture2DMultisampleArray);
+            if (m_GLESCapabilities.SupportsTextureCubeMapArray) {
+                m_dynamicParameters.PerLayerFramebufferAttachmentTargets |=
+                    DynParams::PerLayerFramebufferAttachmentBit(TextureTarget::TextureCubeMapArray);
+            }
+        }
         // Not a driver question and never will be: OpenGL ES has no double-precision vertex format
         // and ESSL has no fp64 type to consume one with, so a 64-bit vertex attribute has nowhere to
         // land on this backend regardless of what the driver underneath happens to support.