Make the code compatible with conda packaging

[olivier-roussel]

SOFA has dropped support of the Qt GUI in favor of this GLFW / ImGui GUI plugin. We need to package this pugin in conda as well if we want to keep a "usable" (i.e. with a GUI) SOFA version for the next release, but there is a point we need to settle.

Some fetched dependencies can't be externalized through a find or fetch mechanism. The problematic case here is imgui. imgui repository manages two branches of its sources: master (default) and "docking". The "docking" branch offers advanced features such as Docking and Multi Viewport, and SofaGLFW rely on the "docking" version.
These two branches are managed somehow in parallel, and each release provides a release of both. This "versioning" pattern is poorly compatible with packaging systems such conda, and the conda package for imgui only match to master. As master and "docking" have different API (thus ABI), this cannot be handled by conda packages variant (see conda-forge/imgui-feedstock#22). And both version have same names so having separated packages for each does not seem to be a good idea (risk of mixing installed versions).

Fetching imgui docking branch code for the conda package and linking statically with it can still be OK under some conditions we need to discuss:

1. We chose to make the conda package of SofaGLFW pure runtime (we ship only the binaries, no headers). This suppose that the only consumers of the plugin (i.e. projects that will link with) will be end applications such as runSofa. The problem with shipping SofaGLFW headers is that they include headers of imgui, which may be problematic if another version of imgui is installed.
2. We change SofaGLFW code to encapsulate imgui includes into implementation. At first, it looks that imgui headers are included in public headers only for using imgui types in our API. If we manage to encapsulate all imgui headers, then we could distribute them as well in the package and have a development version.

In both cases, we should hide (i.e. do not export) imgui symbols in our binaries, or we would have to be sure that no other plugin/application that will link to SofaGLFW will link also with some imgui version.

Option 1 looks straightforward and might be a good first solution. The main downside I see (apart from being limited to runtime) is that the package would not be homogeneous with other SOFA plugins packages which are all in their development version.

Could you also confirm that no other SOFA plugins uses this plugin headers ?