Fix resolving DS with different formats

[K0bin]

Fixes #3386

This fixes 3 different validation errors in that game.

Resolves

Resolves hit the new temp image code path which didn't account for depth stencil (or passing VK_FORMAT_UNDEFINED as the resolve format) at all. So we ended up creating an image with VK_FORMAT_UNDEFINED and there were a ton of usage and image aspect errors.

It uses the new code path because the check for view compatibility fails because that check doesn't account for VK_FORMAT_UNDEFINED. resolveImageFbDirect will just get the formats off the srcImage & dstImage if it receives VK_FORMAT_UNDEFINED, so the format will automatically be compatible.

0 sized clears

Fairly self explainatory.

Image layout error with feedback loops

err: Validation Error: [ VUID-VkImageMemoryBarrier2-oldLayout-01197 ] Object 0: handle = 0x2100ef03060, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x2c8c6e7d | vkCmdPipelineBarrier2(): .pImageMemoryBarriers[0] VkImage 0xfd2cdd000000045a[] cannot transition the layout of aspect=1 level=0 layer=0 from VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_ATTACHMENT_FEEDBACK_LOOP_OPTIMAL_EXT. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.239.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier2-oldLayout-01197)

This was caused by the following events:

• call changeImageLayout to change to a feedback loop layout
• this calls spillRenderPass(true)
• this checks whether there's a render pass bound. There isn't. In that case it checks whether there's a suspended render pass end, which is the case, and ends that with transitionRenderTargetLayouts()
• this then stores the layout of the images currently bound as RTs: m_rtLayouts.color[i] = color.view->imageInfo().layout;
• immediately after this, we change the layout of that image

So to fix this, I just opted to update the tracked render target layouts in changeImageLayout if necessary.

[doitsujin]

one nit