Add VKB_BUILD_SHADERS cmake option to control shader build

[SRSaunders]

Description

This PR adds a new VKB_BUILD_SHADERS cmake option (default ON) to control whether shaders are built for the project. Currently shaders are always built even though they are already available in pre-built form as part of the project. This seems wasteful unless the end-user actually wants to modify shaders and rebuild. In addition, this adds to build time for a project that already has long build duration (~9 minutes).

As part of this PR, this new option is used to turn off shader compilation for iOS CI builds. iOS is unique in that it requires the SDK to be available during CI for packaging and app bundle creation reasons. A side-effect of this is that shader compilers are therefore available to the iOS CI build and shaders are always built, which is wasteful.

This PR also removes a short term workaround that @SaschaWillems put in place disabling slang shader compilation for iOS CI builds. This is no longer needed for several reasons: a) current iOS/macOS SDKs contain working slang compilers, and b) the new VKB_BUILD_SHADERS option is used to turn off shader compilation for iOS CI in this PR.

Some project build time comparisons (with SDK and/or shader compilers installed):

macOS Sequoia on x86_64 6C/12T using Xcode 26.3 debug build:
VKB_BUILD_SHADERS=ON: 490 seconds
VKB_BUILD_SHADERS=OFF: 413 seconds (14% improvement)

Windows 11 VS 2019 debug build (exact same machine as above but booted into Windows 11):
VKB_BUILD_SHADERS=ON: 517 seconds
VKB_BUILD_SHADERS=OFF: 480 seconds (7% improvement)

Note I have set the default value for VKB_BUILD_SHADERS to be ON for backwards compatibility, there may be a good argument to set the default value to OFF. I will wait for feedback from maintainers on this point.

Fixes #

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