Port the build system to a CMake one and integrate into Github Actions CI

[sisco0]

Is your feature request related to a problem? Please describe.
This could solve problems related to NVIDIA target specification as it has been shown to be present in #172. This issue represents a long-term solution for the project.

Describe the solution you'd like
It would be good for developers to have a CMake-based approach for building the current project. In this way, we could ease the task of compilation and automate some configuration flags by the .cmake files already prepared for each dependency. Also, take into account that the developers would benefit from this approach as they would get a better-simplified view of the build process in the root CMakeLists.txt file.
Take into account that, if we take this approach further, we could achieve a native compilation of the project under different platforms, such as the one pursued in #7.

Describe alternatives you've considered

1. CMake is the standard de facto for generating build configuration files in different platforms.
2. Bazel is another alternative that is alright for more complex environments.

The next list of sorted tasks is attached to this issue:

• Create a CMake build system with tests (feat/Added CMakeLists.txt file to the project #174)
• Merge this PR
• Set Github Actions for Continuous Integration workflows (feat/Enable Github Actions CI CMake build #176)
• Merge this PR

[sisco0]

The PR created takes into account the execution of a bash file for the OpenCL builds.
For ensuring multi-platform build support, we should remove the need of using stringify_ocl_krnls.sh and version_string.sh bash files, this second functionality was integrated successfully into the CMake process, but the first one is not done so maybe OpenCL build does not work for Windows yet.

This should be set in a new issue after CMake and Github Actions CI gets merged, as this would require us to follow one of the next two alternatives:

1. Set the OpenCL kernel code to be defined only in the source code file generated by the stringify_ocl_krnls.sh file and remove the cl input files.
2. Use a method for loading and compiling the .cl kernel input file, which must be copied to the binary same folder of the application. In this way, we do not need to stringify anything and the .cl file is dinamically loaded up.
3. Do not use a bash file but include this file generation process in CMake. See reference.

I discourage the first option, as we would lack the ability to debug the kernel directly through other OpenCL development tools; also, code formatters would not work as expected. These alternatives should be discussed in the new issue that has to be created.

[atillack]

@sisco0 Carrying around the OpenCL source files externally is not a good alternative. OpenCL sources should be part of the binary - if you can implement 3) please do so.