Added support for Conan as a dependency manager

[jellespijker]

This PR is part of the following PRs:

• libArcus-> Added support for Conan as a dependency manager libArcus#122
• libSavitar -> Added support for Conan as a dependency manager libSavitar#36
• libCharon -> Added support for Conan as a dependency manager libCharon#33
• pynest2d -> Added support for Conan as a dependency manager pynest2d#11
• Uranium -> Added support for Conan as a dependency manager Uranium#720
• CuraEngine -> Added support for Conan as a dependency manager CuraEngine#1479
• Cura -> Added support for Conan as a dependency manager Cura#10535

The purpose of these changes is to set up a dependency manager for Cura and here repositories. Cura uses both third-party and Ultimaker maintained dependencies, written in both Python and C++ (or mixtures of both). Not all of these dependencies can be downloaded with the help of a dependency manager such as pip. This makes setting up Cura from source, a pain in the $%^#$$%^. See the graph below for the current dependencies. Adding to the complexity is the way how we're currently consuming third-party dependencies; Some have to be present on the system/provided by the user, some are shipped within the repo, while others are downloaded by CMake.

All of the above-mentioned PRs and this one, add a conanfile.py to the root of this project. This is a recipe written in Python which instructs Conan (https://docs.conan.io/en/latest/) how to build and package the repository in such a way that it can be reused by other dependencies. If a required dependency has no binary for your OS and compiler it will build that dependency from scratch and store it in the cache. Making installing Cura from source as simple as:

conan install Cura/4.10.0@ultimaker/testing --build=missing

For a more detailed description see the README.md in this repository https://github.com/jellespijker/conan-um

For testing purposes, I have set up a small home server that can be used by Ultimaker employees. Other developers can test this by cloning the above-mentioned repositories and performing a conan export . ultimaker/testing in each root. That only leaves the SIP package, if you execute a conan export . riverbankingcomputing/testing in this folder https://github.com/jellespijker/conan-um/tree/main/recipes/sip it creates a Conan package for SIP 4.19.25

You can use your own profiles for this, but I have personally tested and developed them with my own jinja template profiles on Linux Manjaro with a GCC compiler, Mac OS Big Sur with a Clang compiler and Windows 11 with a Visual Studio 2019 compiler.
These profiles can be installed with the conan config install https://github.com/jellespijker/conan-config. Make sure you add -pr:b cura_release.jinja -pr:h cura_release.jinja to your install instructions

Conan allows for multiple ways of working. Either the exiting package can be used from the cache, or if you want to work on multiple repositories you can put that repo in editable mode such that the xxx-config.cmake in the project that is depending on the other, will point to the paths of your repo, see https://docs.conan.io/en/latest/developing_packages/editable_packages.html

Because the best practice method to use Conan, which is also the preferred way in Conan 2.0, is to use ( https://docs.conan.io/en/latest/reference/conanfile/tools/cmake.html ) With the tools CMakeDeps, CMakeToolchain, and CMake. The CMakeDeps class will generate xxx-config.cmake files per dependency, while the CMakeToolchain will generate a toolchain to be passed to CMake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake These two prepare the way for CMake to actually build the project such that it won't need to change the CMakeLists.txt. Allowing Conan to be optional and not mandatory. Because this project imports polyclipping as Clipper I had to make some small adjustmenst to the CMakeLists.txt this shouldn't affect the build interface

Still, WIP at the moment, since I'm finalizing some last changes across all repos.