Refactor device extension handling

[asuessenbach]

Description

Similar to what we've done in #1455, I refactored the device extension handling.
Instead of the add_device_extension and get_device_extensions functions, we now have a request_device_extensions, exactly like we already have a request_instance_extensions.

Build tested on Win11 with VS2026. Run tested on Win11 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

• My code follows the coding style
• I have reviewed file licenses
• I have commented any added functions (in line with Doxygen)
• I have commented any code that could be hard to understand
• My changes do not add any new compiler warnings
• My changes do not add any new validation layer errors or warnings
• I have used existing framework/helper functions where possible
• My changes do not add any regressions
• I have tested every sample to ensure everything runs correctly
• This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

• I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
• My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

• I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• I have tested the sample on at least one compliant Vulkan implementation
• If the sample is vendor-specific, I have tagged it appropriately
• I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• Any dependent assets have been merged and published in downstream modules
• For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
• For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[tomek-brcm]

Nit: VK_EXT_DEBUG_MARKER_EXTENSION_NAME is now requested unconditionally (as Optional) in the base request_device_extensions(), whereas before it was only added once the code had already confirmed debug_utils wasn't set via VK_EXT_DEBUG_UTILS. This is harmless (Optional, so no failure) but can enable an unused device extension when debug-utils is already active via the instance extension — a minor cleanliness nit, not a bug.

[asuessenbach]

Nit: VK_EXT_DEBUG_MARKER_EXTENSION_NAME is now requested unconditionally (as Optional) in the base request_device_extensions(), whereas before it was only added once the code had already confirmed debug_utils wasn't set via VK_EXT_DEBUG_UTILS.

Good point.
Changed code to request VK_EXT_DEBUG_MARKER_EXTENSION_NAME (as Required) only when debug_utils points to a vkb::core::HPPDebugMarkerExtDebugUtils.

The merge-base changed after approval.

[tomek-brcm]

Vulkan-Samples/samples/api/swapchain_present_timing/swapchain_present_timing.cpp:814:9: error: 'add_device_extension' was not declared in this scope; did you mean 'request_device_extensions'?
814 | add_device_extension(VK_KHR_PRESENT_ID_2_EXTENSION_NAME);
| ^~~~~~~~~~~~~~~~~~~~

[asuessenbach]

@tomek-brcm I'm sorry, that was a rebase/merge issue. Should be fixed now.

[SaschaWillems]

Successfully tested on Android 17 with a Google Pixel 9.