extensions/khr: Take the remaining p_next-containing structs as &mut

[MarijnS95]

Fixes #740

Version 2 of get_physical_device_surface_capabilities and the matching vk::SurfaceCapabilitiesKHR struct exist solely to provide an sType and pNext field to allow extending the original query with additional data via extension structs. However, this API when introduced in #530 only returns the default()-initialized struct making it just as constrained as get_physical_device_surface_capabilities(). Solve this by taking vk::SurfaceCapabilities2KHR as &mut just like any similar API.

And just like this, do the same for the remaining:

• AccelerationStructure::get_acceleration_structure_build_sizes()
• ExternalMemoryFd::get_memory_fd_properties()
• ExternalMemoryWin32::get_memory_win32_handle_properties()

In case these structs get extended somewhere down the line, which the Vulkan API allows for.

[MarijnS95]

Searching for default, we only have:

• AccelerationStructure::get_acceleration_structure_build_sizes;
• ExternalMemoryFd::get_memory_fd_properties;
• and ExternalMemoryWin32::get_memory_win32_handle_properties

that are default()-initializing a pNext struct, perhaps those should get the same treatment (in this PR) to get rid of this problem altogether?

(On a side-note get_device_acceleration_structure_compatibility() is the only other function calling default() but for a flag where we typically use mem::zeroed() instead)

[Ralith]

perhaps those should get the same treatment (in this PR) to get rid of this problem altogether?

SGTM.