[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/BackendObject.h

@@ -358,7 +358,28 @@ namespace MobileGL {
             // glFramebufferTextureLayer, so it does; DirectVulkan maps a GL layer onto a Vulkan
             // array layer with no notion of a 3D depth slice, so it does not yet. Defaults to false
             // so a backend that never sets it gets the conservative answer.
-            Bool SupportsPerLayerFramebufferAttachment = false;
+            // Which layered texture targets this backend can attach ONE layer of to a framebuffer
+            // and then really clear, render and read back that layer. Bit (1u << TextureTarget) is
+            // set for each supported target. Deliberately per target rather than one flag: the three
+            // ways a GL layer maps onto Vulkan are independent capabilities. A 2D or 2D multisample
+            // array layer IS a VkImage array layer and needs nothing extra; a 3D texture's layer is
+            // a z slice, which needs a 2D-array-compatible image and a per-slice clear that
+            // vkCmdClearColorImage cannot express; a cube map array needs an image shape and the
+            // imageCubeArray feature before it can be attached at any layer at all. Defaults to 0 so
+            // a backend that never sets it gets the conservative answer.
+            Uint32 PerLayerFramebufferAttachmentTargets = 0;
+
+            static constexpr Uint32 PerLayerFramebufferAttachmentBit(TextureTarget target) {
+                return (static_cast<Int>(target) >= 0 &&
+                        static_cast<Int>(target) < static_cast<Int>(TextureTarget::TextureTargetCount))
+                           ? (1u << static_cast<Uint32>(target))
+                           : 0u;
+            }
+
+            Bool SupportsPerLayerFramebufferAttachment(TextureTarget target) const {
+                const Uint32 bit = PerLayerFramebufferAttachmentBit(target);
+                return bit != 0 && (PerLayerFramebufferAttachmentTargets & bit) != 0;
+            }
             // Whether glVertexAttribLFormat / glVertexArrayAttribLFormat can be honoured, i.e.
             // whether a 64-bit vertex attribute can actually reach a shader unconverted. Detected,
             // never assumed: DirectVulkan needs VkPhysicalDeviceFeatures::shaderFloat64 (the