peaufiner encore le release workflow

Bon, on a bien galéré sur les deux premières release mais on s'est bien amusés et ça nous permet de bien assimiler les subtilités de git et de l'API Gitlab.

Il faut maintenant résoudre plus ou moins définitivement certaines choses :

• Le tag 0.1.1 fait référence à un commit qui n'est ni dans dev, ni dans main, donc release-it ne va pas le retrouver pour la prochaine release, c'est débile.

• Cette erreur est due au squash de !99 (merged) où le tag a été créé, et au fait qu'on utilise l'option par défaut git.getLatestTagFromAllRefs: false dans release-it.

• Tout ça incite à clarifier et rationaliser encore un peu plus le workflow : il faut vraiment que la partie tag & release Gitlab ait lieu dans main, à la toute fin, et sans commit de release à re-merge dans dev derrière. Il faut donc revoir notre .gitlab-ci les configurations Release-it de la manière suivante :

Reconfigurer Release-it :

• git.commit: false pour que le tag soit sur le dernier commit de main (le merge commit), donc aucun risque d'avoir besoin de merge dev <- main
• git.getLatestTagFromAllRefs: true pour que Release-it aille chercher le dernier tag dans toutes les références, pas juste dans la branche actuelle (ça servira à court terme pour que 0.1.1 soit trouvé la prochaine fois, et à long terme pour faire des releases beta/rc dans dev qui tiennent compte de la version de main)

Revoir le worflow :

1. dans une branche via MR, préparation de la release :
   1. bump des numéros de version
   2. écriture du changelog
   3. 🔴 pas de commit ni de release
2. merge dev <- prepare-release-branch
3. merge main <- dev
4. commit sur main = trigger du job de release, avec uniquement le tag et la release Gitlab, aucune écriture et donc aucun commit étranger à dev

cc. @f00wl je crois que cette fois on a le truc. Reste à corriger l'état actuel de 0.1.1, je peux m'y pencher.