Migrate icub-main and icub-firmware-shared to conda-forge

[traversaro]

This is an instance of https://github.com/robotology/robotology-superbuild/issues/752 .

At the moment, the biggest package that we uploaded to robotology channel is icub-main. I have always preferred to avoid migrating also it to icub-main, mainly for two reasons:

• All icub-* repos tend to have tag that are quite close in time, and that may not fit well with conda-forge migrations strategies
• Our icub-main packages in robotology contain also the esdcan yarp device, that depends on proprietary software (that we ship in the esdcan conda package). If we move icub-main to conda forge, we can't ship this.

However, given recent issues like https://github.com/robotology/robotology-superbuild/issues/1572 and https://github.com/robotology/robotology-superbuild/pull/1583, I think that the upsides may be soon overshadow the downsides. In particular, I think we can overcome the esdcan problem by moving the esdcan device in a separate yarp-device-esdcan conda package, a bit like we already do with idyntree-matlab-bindings and casadi-matlab-bindings .

[traversaro]

Also ergocub-software is a candidate for this.

[traversaro]

Also ergocub-software is a candidate for this.

Done in https://github.com/conda-forge/staged-recipes/pull/26175, this will ensure that we have ergocub-software package on all architectures, and we can quickly have a conda package right after a new release is tagged in the ergocub-software repo. fyi @Nicogene @xela-95

[traversaro]

PR for doing this: https://github.com/conda-forge/staged-recipes/pull/27672 (mainly as a stepping stone to have human-dynamics-estimation on conda-forge and hence on linux-aarch64).

fyi @GiulioRomualdi @S-Dafarra @carloscp3009 @giotherobot