Vulkan loader doesn't handle extensions provided by layers
Sometimes, Vulkan extensions are provided by layers. These are not included in the `glad_vk_get_extensions` logic, and therefore fail to get loaded by glad2.

Possible solutions:

1. Extend the `glad_vk_get_extensions` logic to also enumerate all supported extensions from available instance- and device-level layers.
2. Simply delete the `glad_vk_has_extension` function and load all extension commands unconditionally.
3. Require the user to provide a list of enabled instance- and device-level extensions when calling into `glad2`. (i.e. the `ppEnabledExtensionNames` pointer from `VkDeviceCreateInfo` which the user already has anyway)

I would actually lean towards the second solution, for simplicity and transparent backwards compatibility. According to the Vulkan specification, calling `vkGetDeviceProcAddr` on a function name associated with a non-loaded extension is defined behavior, and requires the driver to return `NULL` here. So unconditionally loading all known function names is kosher.

Calling into non-enabled but supported device-specific extensions is already undefined behavior even if they load successfully, so users must already rely on their own logic to know which device extensions are enabled and which are not, and avoid calling into non-enabled functions. Checking whether the *physical device* supports an extension before attempting to load it does not afford us any extra safety. At best you are saving a few runtime cycles on device creation.