"Unshackle" Renderer from being a mono-instance (and Engine?)

[karnkaul]

DearImGui is a singleton "infection": it cannot accommodate multiple instances, so all types that (directly or indirectly) own an ImGui instance are needlessly constrained to being singletons as well: Renderer and Engine, mainly.

Using an optional interface / instance where the renderer only calls functions on an active instance, and restricting DearImGui to only have one active instance at a time, should "unshackle" Renderer.

Engine will be trickier since it currently also owns (and initializes) Vulkan; possible approaches:

• Engine can keep this responsibility, and expose multiple Window + Renderer instances (only one can have ImGui of course)
• Move ownership of Vulkan outside Engine: undesirable as all windows are polled together, and render queue submits from all windows should be batched (otherwise each window will need its own render loop and frame counter, while being polled simultaneously / centrally)

It probably makes more sense to also restrict Engine to be mono-instanced (like Dear imGui) but upgrade its API to support spawning secondary windows (+ renderers). The latter part is not in scope for this PR / is a stretch goal.

[Rinzii]

Once this issue is closed I‘ll begins working on adding the key binding support with Imgui.