Make `vk::detail::...` reachable but not visible in the C++ module

[sharadhr]

This is parallel to #2111 and the issue that resolved it, #2244. I understand we have VULKAN_HPP_DISPATCH_LOADER_DYNAMIC_TYPE and VULKAN_HPP_DISPATCH_LOADER_STATIC_TYPE, but there needs to be a way to make these names reachable but not visible, that is, users should be able to access their member functions with auto someptr = VULKAN_HPP_DISPATCH_LOADER_DYNAMIC_TYPE.memberFunc(); but should not be able to directly access anything in the vk::detail namespace (as they are part of the implementation detail of Vulkan-Hpp)...

[M2-TE]

What if we were to create a vk::DispatchLoader class that is either templated to represent static/dynamic dispatch loaders, or simply make use of inheritence to unify their interfaces? This will also reduce confusion for newcomers.

The class can be instantiated by users for multi-GPU scenarios, or we can allow users to load the default one via vk::getDefaultDispatchLoader(). These can very easily be used to replace the contents of existing dispatch loader macros like VULKAN_HPP_DISPATCH_LOADER_(STATIC/DYNAMIC)_TYPE and VULKAN_HPP_DEFAULT_DISPATCH_LOADER_DYNAMIC_STORAGE without any breakage. This means that the interfaces users interact with (directly or via macro) are in the vk:: namespace.

I've been thinking about ways to merge the static/dynamic dispatch loaders into a single interface anyways, all while keeping the ability to still be using custom ones. I have a few ideas regarding that which might remove a ton of templating from functions and improve the main complaint about Vulkan-Hpp, i.e. compile times.

[sharadhr]

What if we were to create a vk::DispatchLoader class that is either templated to represent static/dynamic dispatch loaders, or simply make use of inheritence to unify their interfaces? This will also reduce confusion for newcomers.

Great ideas; I've been wondering why we had two separate dispatchers with different interfaces in the first place.

As for compile times, I think reducing templating will help, but there's also the sheer LoC concern; we are around $10^{5}$ lines anyway, and I don't think there's much way to fix that.