[WIP] Renderer backend selection

[revmischa]

This pull request refactors the libprojectM rendering pipeline to improve modularity and OpenGL backend integration. The changes primarily involve replacing the use of a generic RenderItem base class with a more specific OpenGLRenderItem class, updating initialization methods, and introducing a unique pointer for texture flipping. These updates aim to streamline the rendering process and enhance maintainability.

Transition to OpenGL-specific Rendering:

• Replaced the inheritance of Renderer::RenderItem with libprojectM::Renderer::Backend::OpenGL::OpenGLRenderItem in multiple classes, including Border, CustomShape, CustomWaveform, DarkenCenter, Filters, and FinalComposite. This change ensures the rendering logic is explicitly tied to the OpenGL backend. [1] [2] [3] [4] [5] [6]

• Updated initialization calls from RenderItem::Init() to Init() in constructors across several classes to align with the new base class implementation. [1] [2] [3] [4] [5] [6]

Texture Flipping Refactor:

• Replaced the Renderer::CopyTexture instance with a std::unique_ptr<Renderer::CopyTexture> to manage the texture flipping filter. This change improves memory management and ensures proper cleanup. [1] [2] [3]

• Updated calls to the Draw and Texture methods of m_flipTexture to use the new unique pointer syntax (m_flipTexture->Draw and m_flipTexture->Texture). [1] [2] [3] [4]

Header File Updates:

• Replaced #include <Renderer/RenderItem.hpp> with #include <Renderer/Backend/OpenGL/OpenGLRenderItem.hpp> in header files to reflect the new OpenGL-specific base class. [1] [2] [3] [4] [5] [6]

Code Cleanup:

• Removed redundant or outdated comments and documentation blocks in CustomWaveform and FinalComposite to simplify the code and improve readability. [1] [2]

[kblaschke]

Just as a comment here: Please don't remove the Doxygen comments from the classes (e.g. this one). They may look hard to read in the code, but enable us to generate a proper code documentation from it once all classes are properly commented/documented. If a comment is outdated after editing/refactoring something, it should rather be updated to reflect the current state.

Only documentation of:

• override methods which already have a doxygen comment in the base class and don't have a notable extra functionality and
• private functions/members which are self-explanatory

can/may be removed.

Most modern IDEs also provide a nice rendering of these Doxygen comments directly in the source tree. These IDEs (e.g. CLion) also show the parameter docs when hovering over a call or typing the function arguments, which is more information than just the declaration provides.