API/CMake and general improvements

[JohannesKauffmann]

Some points of improvements I noticed:

• When building with -DENABLE_CXX_INTERFACE=ON, it seems like ProjectM.hpp includes PipelineContext.hpp, but does not install that header file, resulting in compilation failure.
• Related to this, ProjectM.hpp includes PipelineContext.hpp directly without a relative path to the Renderer folder in which it resides. Assuming PipelineContext.hpp gets installed to $CMAKE_INSTALL_PREFIX/include/libprojectM/Renderer, either the #include statement should reflect it's location, or the extra include directory should be exposed in the public CMake/pkgconfig interface.
• ProjectM.hpp relies on a USE_THREADS define. This is fine when building ProjectM itself, but for libraries, this flag does not get propagated. _Side note: it maybe better to rename this to PROJECTM_USE_THREADS to prevent possible name clashes._
• Installing the static library installs libprojectM.a to the lib folder, but -l:projectM.a is added to the pkgconfig file (and thus linking fails). For shared builds, no pkgconfig file is written.
• Related: the debug prefix (d by default) is not propagated to the pkgconfig file.
• The OpenGL library usage requirements are not propagated to the pkgconfig file, leading to linker failures. The same goes for omp_get_num_threads and friends, whereever that comes from.
• Last but not least, does ProjectM provide a version define, to faciliate projects conditionally using either an older or newer version? Something like PROJECTM_MAJOR, PROJECTM_MINOR possibly.

[kblaschke]

All good points!

• The C++ interface probably needs even more headers, or a good amount of cleanups to reduce the number of required headers. another approach would be installing most C++ headers so downstream apps can tap into more code here, especially when linking it statically. Shared library exports on Windows would require to export declspec attributes to all these classes while not being something officially endorsed, so I'd rather not go down that path.

• The USE_THREADS define can simply be exported in the INTERFACE compiler defines of the target if the C++ API is enabled. This will automatically add the define in downstream projects.

• The pkgconfig output is basically a 1:1 copy of what the old automake/autoconf scripts generated. I didn't touch it since then, so yes, it'll require some work to be usable again. It also needs to be updated with additional link libraries (like OpenGL), compiler defines etc. to work properly in non-CMake projects.

• The library version can either be queried via CMake after find_package via the libprojectM_VERSION variable. this variable can be split into components with CMake's string command. On the API side, there's currently no way to query the version during compile time. We should definitely add it in a separate libprojectM/version.h header, both as numerical defines and a full-version string.

[kblaschke]

Most API changes are finished, so I can now get into polishing all those small things. Some parts of this issue are already done, others like pkgconfig and the library version are still to do.

[kblaschke]

Everything's implemented now in master. See version.h and the new projectm_get_version*() functions in core.h to retrieve version numbers in code for build and runtime versions of libprojectM.