Proposal: debug naming of subresources

### Problem
When an application suballocates or reuses `VkBuffer`s or `VkImage`s, the object itself may have no meaningful identity - but the current debug naming API `vkSetDebugUtilsObjectNameEXT` and friends cannot name subresources, which makes it difficult for developers to get meaningful debug name readout. Furthermore, resource suballocation is an idiomatic way of using Vulkan.

Persistent identity subresources, where the application has suballocated from a buffer/image, but the identity of the subresource is tied to the host timeline. An example is suballocating a large buffer to hold the indices of a specific mesh - in this case the application would name the subresource before it is being used with an identifier, eg. `'Suzanne.glb - indices'`, and this name-subresource link would be persistent until the subresource is reused.

### Proposal
Persistent identity subresources: a straightforward extension of VK_EXT_debug_utils, which allows the naming of subresources
```c
struct VkDebugUtilsBufferRangeInfoEXT {
VkStructureType sType;
const void* pNext;
VkDeviceSize offset;
VkDeviceSize size;
const char* pObjectName;
};

struct VkDebugUtilsImageSubresourceInfoEXT {
VkStructureType sType;
const void* pNext;
VkImageSubresourceRange subresource;
const char* pObjectName;
};
```
These structures can be chained to `VkDebugUtilsObjectNameInfoEXT`, when the named object is a `VkBuffer` or `VkImage`, respectively.

### Discussion
- All identifiers and API snippets are just for explanation of course.

cc. @nanokatze @Dolkar

Start with the issue's proposal and the existing VK_EXT_debug_utils definition, especially VkDebugUtilsObjectNameInfoEXT and its handling for VkBuffer and VkImage. Determine whether the proposed buffer-range and image-subresource naming requires a specification extension; done would be an agreed design and corresponding Vulkan-Docs changes, but no target files or tests are identified here.

Written by the indexing model from the issue text.