device_memory_report: guard extension device commands in vkGetInstanceProcAddr

[jimblacklercorp]

This PR hardens command dispatch in the VK_LAYER_GOOGLE_DeviceMemoryReport layer by ensuring extension device commands queried via vkGetInstanceProcAddr are verified against the underlying dispatch chain before returning interceptors.

Summary of changes:

• Separate global, core, and extension device commands:
  • Global functions (vkCreateInstance, vkEnumerateInstanceExtensionProperties, vkEnumerateInstanceLayerProperties, vkGetInstanceProcAddr) are handled first without requiring a valid instance.
  • Return early if instance == nullptr for non-global functions.
  • Core device commands continue to be returned directly from vkGetInstanceProcAddr.
  • Extension device commands (vkBindBufferMemory2KHR, vkBindImageMemory2KHR, vkGetImageMemoryRequirements2KHR, vkGetBufferMemoryRequirements2KHR) query the downstream dispatch table first. If unsupported by the underlying driver/layer chain, vkGetInstanceProcAddr returns nullptr to avoid applications falsely detecting unsupported extensions.
• Add assertions in KHR bind commands:
  • Added assertions in vkBindBufferMemory2KHR and vkBindImageMemory2KHR to ensure dispatch table entry points are non-null when called.

[olehkuznetsov]

Thanks for working on this! Hardening extension dispatch and cleaning up handle lifetimes are great improvements.

A couple of architectural observations on the two commits in this PR:

1. Commit 1 (guard extension device commands in vkGetInstanceProcAddr):
   The split between core and extension device commands is the right direction, but in the current implementation, devmemreport_known_device_extension_functions returns nullptr, while the 4 intercepted KHR commands (vkBindBufferMemory2KHR, vkBindImageMemory2KHR, vkGetImageMemoryRequirements2KHR, vkGetBufferMemoryRequirements2KHR) were left in devmemreport_known_core_device_functions.
   Because GIPA returns core device commands without querying downstream, the extension guard at lines 89–103 is never actually reached for any extension command—making the commit a functional no-op as-is. Moving the 4 *KHR functions into devmemreport_known_device_extension_functions makes the guard work as intended. (See inline comment for snippet).
   (Additionally, in device_memory_report_handwritten_functions.h, vkBindBufferMemory2KHR and vkBindImageMemory2KHR currently dereference device_dispatch_table(device)->Bind*Memory2KHR without null-checking—unlike GetImageMemoryRequirements2KHR which has a null guard. Adding null checks there will protect against crashes regardless of whether an application resolves these commands via GIPA or GDPA).

2. Commit 2 (pass VkObjectType to OnDestroyObject):
   OnDestroyObject accepts VkObjectType object_type, but the parameter is unused—the internal tables (resources_ and resource_to_memory_map_) remain keyed strictly on uint64_t, and creation hooks (OnCreateImage/OnCreateBuffer) do not store the type either.
   On 64-bit platforms (Android / Linux), distinct live buffers and images having identical 64-bit handle values is not demonstrable in practice. Unless there is an active plan to convert resources_ to composite keys (struct ResourceKey { VkObjectType, uint64_t }), we recommend dropping/reverting this commit to avoid churn across 16 call sites (production dispatch + unit tests).

Detailed inline comments with suggested fixes are below.