Defferred initialization

[pchome]

Maybe entry points are not the best places to init some internal stuff. Because every damn thing requesting vulkan also triggering Config constructor.

This causes:

• spam in the log output/file
• multiple file operations which can (at some point) burn a hole in users config file (jk)

Effects should "play dead" as long as possible. This is how the trace log looks like after I moved Config creation into vkCreateSwapchainKHR:

[entries before an actual action] (click to view)

``` ... vkBasalt trace: vkCreateInstance vkBasalt trace: vkDestroyInstance vkBasalt trace: vkCreateInstance vkBasalt trace: vkDestroyInstance vkBasalt trace: vkCreateInstance vkBasalt trace: vkDestroyInstance vkBasalt trace: vkCreateInstance vkBasalt trace: vkDestroyInstance vkBasalt trace: vkCreateInstance vkBasalt trace: vkDestroyInstance vkBasalt trace: vkCreateInstance vkBasalt trace: vkCreateDevice vkBasalt debug: device supports VK_KHR_swapchain_mutable_format vkBasalt debug: activating mutable_format vkBasalt trace: vkGetDeviceQueue vkBasalt debug: found graphic capable queue vkBasalt trace: vkGetDeviceQueue vkBasalt trace: vkDestroyDevice vkBasalt debug: DestroyCommandPool vkBasalt trace: vkDestroyInstance ... ``` ^ here will be the final create and everything else. Imagine configuration output after every `vkBasalt trace: vkCreateInstance` (how it currently is), also some applications can be even more "evil".

Well, vkCreateSwapchainKHR not the best place too, maybe you know better solution.

[DadSchoorse]

The problem is that the config is needed in vkGetDeviceProcAddr (and maybe even vkGetInstanceProcAddr but I'm not 100% sure) to check if we need to intercept more functions for depth capturing.

[pchome]

IDK, maybe replace this check with getenv(VKBASALT_EXPERIMENTAL) ; or just report them unconditionally, and then check inside if you need to do additional stuff; idk...