Copie pour une branche totalement expérimentale, pour tester sans gêner s'il est possible d'avoir un comportement au maximum automatisé, qui n'impose pas aux gens de modifier les squelettes de listes pour que ça marche.

Nettoyage : le déplacement de l'ancienne config n'a pas à se faire à chaque hit PHP, on a des fonctions de mise à jour pour ça.

Nettoyage : aucune raison de stocker la config dans une liste à virgule avec ensuite des explode partout dans le code ensuite, alors qu'on sait parfaitement enregistrer nos configs en tableaux et listes. Donc on met à jour la base pour transformer l'ancien stockage, et on met à jour le code en conséquence. Au passage aussi, pas besoin de remettre un préfixe rang_ devant le nom de la config puisque désormais on est déjà dans un casier rang/.

Correction gros bug : le plugin supprimer les champs rang même sur les tables qui l'avaient déjà avant. Du coup on fait une fonction avec static qui garde en mémoire les tables avec ce champ déclaré avant que Rang ne complète la déclaration des objets. Et du coup lors de la désinstallation on a cette liste pour ne pas supprimer. Au passage on ne déclare aussi que si le champ n'est pas déjà déclaré.

On arrive à remplir le data-objet et le data-id_objet automatiquement, sur toutes les listes d'objets classiques. Reste à affiner la détection du parent sur vraiment tous les types de parent (ex objet/id_objet certains), et surtout à n'activer le rangement quand la liste est triée par Rang, ce qui n'est pas forcément le cas par défaut, et n'a d'ailleurs pas à l'être (il y a plein de cas où on veut que telle liste soit par défaut affichée par date, par titre, ou autre).

1) On vire toutes les modifs par regex, c'est fini ce temps là. On utilise le DOMDocument qui est standard dans PHP et qui marche très bien et qui fait de la vraie analyse syntaxique, c'est très solide et propre. 2) On ajoute une colonne Rang *si pas déjà* bien sûr et on met un lien qui permet de trier dessus, car pour l'instant je ne sais pas encore comment faire pour forcer le tri en avance, car il n'y a pas de pipeline PRE compilation dans SPIP (et c'est un manque). On approche du but même s'il y a encore des manques, là tout est automatisé et fonctionne pour n'importe quel objet qui n'aurait pas changé son squelette de liste !

On n'ajoute pas de colonne pour l'image de drag, car ça peut péter des colspan ailleurs d'ajouter comme ça des colonnes non prévues (par ex un th qui vaut pour deux colonnes, déjà vu, ou des trucs en tfoot). On le met juste au début de la première colonne existante.

- Je monte la version de saisie (en gardant la même branche pour réduire le risque de casse) pour être certain que si un jour, un commit qui concerne l'un des plug et saisie, que la version de saisies soit une version sûr !
- + broutilles (exemple, mise en adéquation de borne mini de plug dans les "necessite" avec la version de spip pour quoi le plug est fait)

être certain que les plug ont une version de saisies "sûr", normalement, cela devrait être bon, car aucun n'avait de borne max concernant saisies

Changement de la version de "saisie" sauf sur les branches suite à discutions https://zone.spip.net/trac/spip-zone/changeset/116243/spip-zone :)