WIP: proposition pour se debarasser de `datas` et `li_class`

Contexte

Les saisies peuvent avoir une option li_class ainsi qu'une option datas, pour compatibilité historique. Les noms corrects sont désormais conteneur_class et data.

Proposition

• Ne plus proposer la compatibilité à partir de la version 4.0.0 du plugin.
• La difficulté est que les formulaires construit à partir des .yaml ont des 'datas' et 'li_class' dans la liste de leur saisies.
• Dans la branche 3
  • fournir une fonction de migration, que l'on pourrait appeler les plugins qui utilisent le constructeur de formulaire, à savoir champs_extra_interfaces et formidable
    • dans les fonctions de MAJ
    • dans les fonctions d'import depuis un fichier externe
  • changer les .yaml pour qu'ils proposent les options avec les noms modernes
  • on pourra ainsi ne pas forcer tout de suite la maj vers la branche 4
• Il faudra faire une passe sur les plugins sur git.spip.net pour vérifier tous les .yaml et .php qui utilisent datas et li_class

Liste des saisies en dehors du plugins qui ont un argument datas

• saisie_choix_couleur > à réecrire entièrement, avec un mecanisme d'héritage. Ca tombe bien j'en suis l'auteur (et je pense que personne ne l'utilise, même pas moi !)
• podcast, mais il n'y pas de constructeur. Du coup je dirais que ce sera juste une exception. Peut être qu'il faudrait proposer à son / sa responsable de se conformer à la nouvelle syntaxe? ping @kent1

Liste des plugins où on laisse tomber

• jqueryUi, qui n'est pas compatible 3.0, et ne le sera sans doute jamais. Il n'a plus de raison d'être :)