Add support of noexcept-path for vk::raii classes

[asuessenbach]

Resolves #1498.

[theHamsta]

I think the failures for clang-13 are because the compiler does not properly support c++23 yet and requires the typename before the template (which might become obsolete with c++23).

Other failures with newer versions of clang are because the compiler doesn't support __cpp_lib_expected because it also does not fully support concepts yet (the gcc header tests for __cpp_concepts). theHamsta#21 seems to compile almost fine https://github.com/theHamsta/Vulkan-Hpp/actions/runs/7063965682/job/19231032347?pr=21. Vulkan-Hpp headers seem to miss <memory> for unique ptr in the raii headers. clang++-13 compiles locally with these changes fine on my machine.

Overwriting VULKAN_HPP_EXPECTED/VULKAN_HPP_UNEXPECTED might not be possible with older c++ standard as template type deducation is not that advanced D:\a\Vulkan-Hpp\Vulkan-Hpp\vulkan/vulkan_raii.hpp(17380,16): error C2955: 'tl::unexpected': use of class template requires template argument list (they might need tl::make_expected, std::make_pair etc.).

[theHamsta]

I would use the feature test macro __cpp_lib_expected. Clang has <expected> via GCC, but cannot use the feature due to missing full support for concepts.

[sharadhr]

Ah, seems this has been merged. I saw this discussion on Reddit, and one comment in particular seems relevant:

If you're calling a private constructor without using this pattern you are likely incurring an extra copy or move constructor. The basic problem is that you want to return an object of type std::expected<T, E> from the public static function. In order to construct the return object, the constructor of std::expected<T, E> needs to initialize the object of type T in its storage, ideally by forwarding the arguments you provide to construct the T object in place. But std::expected<T, E> can't call private constructors, so the passkey idiom is useful to make a constructor that any callsite can invoke, but that takes a passkey parameter that only members of the class T can create.

It seems one possible way around this is to either use the passkey idiom, or declare std::expected as a friend of the classes we want to protect. I suppose we might choose the latter, since we want to still allow users to directly construct vk::raii::Things...