Make the RenderContext class a singleton, migrate some setup functionality to it

[jherico]

RenderContext and the HPPRenderContext types are required by lots of the more interesting pieces of functionality in the code, and end up getting passed in a function signatures (or alternatively, the RenderContext owner, VulkanSample gets passes, such as in the vkb::Gui class) or a child (almost always a vkb::Device class).

This leads to an excessive number of cases where objects need to retain references to devices or render contexts (consider the Buffer and Image classes which use VMA for all their work, but still have to be initialized with references to vkb::Device because the parent class VulkanResource requires it.

An alternative to this would be to make the RenderContext class a singleton, and ensure that only one exists at any given time, and that all other classes can access it via a static RenderContext::get method that either returns the singleton instance or throws an exception if it hasn't yet been initialized.

This would free a vast number of classes that currently need to be passed a reference to the RenderContext or the Device, or in the case of Gui the VulkanSample from requiring that. In every case the code in question could simply call something like RenderContext::get()->get_device() or something similar.

In such a re-design, the RenderContext should own the initialization of the instance, the physical device and the device as well as the swapchain, allowing a chunk of the code currently in VulkanSample to be migrated to that class.

[SaschaWillems]

I think we should look at stuff like that in the greater scheme of our planned framework refactoring. There are lots of things that need rework or improvement, but maybe we should start to prioritize things and concentrate on more interesting things like new samples. I'm kinda getting the feeling that we're moving to bike shedding territory with all off this and forget about important stuff that needs fixing.

[SaschaWillems]

I also think we shouldn't rush to do all of these things. We already invested a lot of effort into planing the framework rework and @tomadamatkinson is working on that.

[SaschaWillems]

Closing this for now. Our main coal is to unify the framework, but we want to concentrate on adding new samples instead of doing further (large) changes to the framework.