Clarification of VIS operation for WAR/WAW hazards with layout transition

Do we need a VIS operation after an image layout transition in the case of WAR and WAW hazards, or at copying to a newly created image?

Consider the following example:

```
VkImageMemoryBarrier2KHR preCopyMemoryBarrier = {
.srcStageMask = VK_PIPELINE_STAGE_2_NONE,
.srcAccessMask = VK_ACCESS_2_NONE,
.dstStageMask = VK_PIPELINE_STAGE_2_TRANSFER_BIT,
.dstAccessMask = VK_ACCESS_2_MEMORY_WRITE_BIT, // <- Is this really necessary?
.oldLayout = VK_IMAGE_LAYOUT_UNDEFINED,
.newLayout = VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL,
.srcQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
.dstQueueFamilyIndex = VK_QUEUE_FAMILY_IGNORED,
.image = image,
.subresourceRange = ...
};
```

On WAR and WAW hazards, or at just like in the example, transitioning out a newly created image from UNDEFINED into an another layout, there is nothing to make visible, even after the image layout transition - or is it still required to make some kind of image layout related metadata to be visible after the transition?

The question can be rephrased as whether the writes performed by a layout transition should be made visible (`dstAccessMask = VK_ACCESS_2_MEMORY_WRITE_BIT_KHR` in the example) or not, if the next access will only overwrite it without reading.

It should be clarified and spelled out in the specification.

Begin with the WAR/WAW and UNDEFINED-to-transfer example in the issue, then review the relevant Vulkan specification language and the 13-comment thread. Done means reaching a decided interpretation and recording explicit specification wording for whether the layout-transition writes need visibility when the next access overwrites them.

Written by the indexing model from the issue text.