Better way to handle vk khr portability enumeration extension

[hybcloud]

Better way to handle vk khr portability enumeration extension of hard-coded c_str.

Checklist

• Run cargo clippy.
• Run cargo clippy --target wasm32-unknown-unknown if applicable.
• Add change to CHANGELOG.md. See simple instructions inside file.

Connections
#4038
#3958
https://github.com/ash-rs/ash/blob/f5587619979b791c8d37110393c4a9b4c50e0a34/examples/src/lib.rs#L235

Description
The PR enhances the solution of #4038, which solves the bug introduced in #3958 by using ash's KHR definition (semantically, it's the funtion's name, not extension's name, but they share the same name, and ash uses it as extension's name in its own
example code
(https://github.com/ash-rs/ash/blob/f5587619979b791c8d37110393c4a9b4c50e0a34/examples/src/lib.rs#L235)
(In ash's example code just mentioned, they requires another extension called KhrGetPhysicalDeviceProperties2. The extension is a KHR in vk1.0 but soon get into core in vk 1.1, and I don't have a mac to test if it matters, so I choose to keep it right the same as before)
)

Testing
Thanks to #4038, validation layers on windows stop reporting error about VK_KHR_portability_subset. It's a simple enhancement of #4038, and wgpu example (hello-triangle) has been shown to work fine when backends flag is VULKAN.

[Wumpf]

nice catch, thank you for contributing!