Set VK_LAYER_KHRONOS_validation to Optional in case layer not available

[SRSaunders]

Description

This PR fixes a few small issues found when testing on the iOS Simulator, and on Windows 11 with no SDK installed:

1. Changed VK_LAYER_KHRONOS_validation to be Optional for debug builds vs. Required. This applies to all platforms but allows debug builds to run even when the validation layer is not available. This is important for several use cases: a) Windows users who do not install the SDK, and b) on the iOS Simulator where the VVL library is not built or available for that target. I debated this change before making it, but I believe it is correct given that Windows build docs do not mention or require installation of the SDK, and the default build config for Visual Studio is debug. I am interested in feedback from maintainers on this regarding project intentions: i.e. Required forces a runtime error that prevents samples from running in debug mode for the above scenarios, or Optional which allows execution with a runtime warning message instead. I believe the latter is more appropriate.
2. Updated some samples (texture_loading, texture_mipmap_generation, hpp_pipeline_cache, pipeline_cache) to guard against an undefined device on exit. These samples assume the device is defined and attempt cleanup without checking first, which can result in a crash on exit when the sample does not run successfully. I found this in testing item 1 above, i.e. when running in debug mode with VK_LAYER_KHRONOS_validation set to the original Required.
3. Added MoltenVK configuration code to allow dynamic_rendering_local_read to render properly on the iOS Simulator. This is identical code to a few other samples that already use this iOS-specific #ifdef config block for correct rendering on the iOS Simulator: layout_transitions, pipeline_barriers, and subpasses.
4. Updated the gui pipeline creation code to use VK_FORMAT_UNDEFINED for the depth format when using dynamic rendering. While Vulkan technically allows the pipeline to be created with a defined depth format, even while rendering uses a null depth attachment, this is not necessarily the best practice. Looking at docs and recommendations for dynamic rendering, the both the pipeline and rendering steps should indidate that no depth attachment will be used in cases like gui overlay rendering as implemented in this project. Note the gui pipeline already specifies depthTestEnable = false and depthWriteEnable = false so I felt it was appropriate to also set depthAttachmentFormat = VK_FORMAT_UNDEFINED. This has the added benefit of allowed the VVL to identify a mismatch case if the gui ever erroneously specifies a non-null depth attachment during dynamic rendering for the gui. Note I found this issue not from the VVL, but because Metal validation picks it up.

Fixes #1523.

Tested on Windows 11, macOS Sequoia, iOS 26, and iOS Simulator running iOS 26.

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