Module system base

[dpeter99]

This PR adds the base of the Module system. It allows loading the game-specific code at runtime from a DLL.

The game module is loaded based on the run argument -game that specifies a DLL to be loaded. This DLL has to have a shadow_main entry point as an extern "C". The DLL can then add new Modules to the engine. Later this will be the point where they can request additional modules.

The engine has all of its members exported by the build setup, so there is no need to __declspec(dllexport) the things that are needed from the game DLL side.

Changes:

Cmake clean up

• Moved imgui into an auto-downloaded package
• Removed the static copy of imgui
• Using the built-in SDL2 CMake file now
• Moved some separate modules into the shadow-engine folder

Module system

• Added test-game
• For demonstration moved Imgui init to test-game
• Moved SHObject implementations to allow module compilation
• Added debug module
• Cleaned up the core loop
• Added SDL2 module
• Added Module manager

Misc

• Fixed imgui multiple viewports
• Added Window abstraction

[TheCurle]

The engine has all of its members exported by the build setup, so there is no need to __declspec(dllexport) the things that are needed from the game DLL side.

The MSVC packaged with Visual Studio 2022 does not export global or static variables by default. Therefore, the vars in Time.cpp and the instance in ModuleManager must be conditionally imported or exported manually.

That looks something like:

#ifdef EXPORTING_SH_ENGINE
#define API __declspec(dllexport)
#else
#define API __declspec(dllexport)
#endif

Then placing API before the type of global/static declarations will allow the game module to access this information.

[TheCurle]

Other than that, the only thing preventing me from approving this is the major bugs in CLion and Visual Studio that prevent me from being able to debug the engine while the game module is running.