RFC: const-ref based inline helper functions

[pdaniell-nv]

This builds on the previous default member initialization PR (#2669) and adds inline const-ref variants of the existing Vulkan functions that take const-pointer for info structures and similar. This allows temporary objects to be used as parameters, potentially leading to more concise, convenient and readable code. The output of these changes can be seen here:

• RFC: Initial headers from Vulkan usability improvements Vulkan-Headers#591

In addition this PR adds inline variants of the create and destroy functions without the pAllocator parameter to make those functions more concise for the common use case.

For example, this:

VkFenceCreateInfo fenceInfo{ VK_STRUCTURE_TYPE_FENCE_CREATE_INFO, nullptr, VK_FENCE_CREATE_SIGNALED_BIT };
vkCreateFence(device, &fenceInfo, nullptr, &fence);

Can now look like this:

vkCreateFence(device, {.flags{VK_FENCE_CREATE_SIGNALED_BIT }}, &fence);

Finally, this PR adds const span<VkThing>& variants of functions that take a uint_t count, const VkThing* pair to make it easier to work with arrays, vectors and other things that can naturally be viewed as spans.

Code that used to look like this:

vector<VkFence> myFences;
...
vkResetFences(device, (uint32_t)myFences.size(), myFences.data());

Can now look like:

vector<VkFence> myFences;
...
vkResetFences(device, myFences);

With feedback, these API experiments will hopefully evolve into something genuially useful to app developers, make their code more concise, easier to read and maintain, and the Vulkan API more of a joy to use. Other experiments will follow.

[charles-lunarg]

An excerpt from vulkan-headers:

#if VK_CPP20_FEATURES
extern "C++" inline VkResult vkCreateInstance(const VkInstanceCreateInfo& pCreateInfo, VkInstance* pInstance)
{
    return vkCreateInstance(&pCreateInfo, nullptr, pInstance);
}
#endif

For this code to compile, it needs to not have VK_NO_PROTOTYPES because it needs there to the vkCreateInstance symbol defined. Applications that do not link to the Vulkan-Loader (which provides these symbols) will fail to compile. Volk does define the symbols so should work, but I'm not 100% on that. More importantly, it means that (non-wsi) extensions will not work due to having no symbols defined.

Extensions defining symbols that have no link-time definition was enough of a problem the VK_ONLY_EXPORTED_PROTOTYPES macro was added which prevents its definition. Was added in the 1.4.319 header update. That said it only disables these symbols if the macro is defined, so its 'opt in'.

Having overloads which only work for some functions (core and the handful of wsi functions that the Vulkan-Loader exports) is very confusing behavior. I do not think this should be included in the headers unless it is possible to use these overloads for all functions. The current situation of some functions being linkable and some not is already confusing enough.