Fix Vulkan crash with TextureChange::Modified

[patowen]

The TextureChange::Removed and TextureChange::Modified match arms in YakuiVulkan::update_textures both have logic to remove a texture, but the logic is inconsistent between the two arms. This PR changes the TextureChange::Modified branch to be consistent with TextureChange::Removed.

This change also fixes a crash I experienced when trying to change UI text based on in-game information on a game that has a graphics pipeline depth (simultaneous frames in flight) of 2. The following Vulkan validation error appeared during this crash:
Validation Error: [ VUID-vkDestroyImage-image-01000 ] | MessageID = 0xf2d29b5a | vkDestroyImage(): can't be called on VkImage 0xe3343f000000028f[] that is currently in use by VkCommandBuffer 0x20919128700[frame]. The Vulkan spec states: All submitted commands that refer to image, either directly or via a VkImageView, must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-vkDestroyImage-image-01000) id=VUID-vkDestroyImage-image-01000 number=-221078694 queue_labels= cmd_labels= objects=
Setting a breakpoint on the validation error did point me to the TextureChange::Modified match arm.

I am still relatively inexperienced in Vulkan, so I'm not certain this fix is correct nor would I be confident in setting up some kind of test case to be able to reproduce the issue in this repo itself. For extra context, I encountered this issue in Ralith/hypermine#391.

[kanerogers]

Thanks for another fantastic PR - well documented and great explanations.

@Ralith I'll defer sync stuff to you as it's not my strong suit, but happy to take a look myself if you're time poor.

[patowen]

Thanks for the kind words!

[Ralith]

This change makes sense to me. The prior code calls VulkanTexture::cleanup directly upon yakui's TexterChange::Modified, which frees the associated Vulkan resources immediately. The new code instead queues the texture for deferred cleanup, just like removal. In both cases this is required because the texture might still be in use by a previously submitted transfer or draw. I'm surprised we haven't noticed this before!