La gestion auto du multi-étapes casse celleux qui font du multi-étapes de leur côté sans l'API PHP

Le cas où ça pète est tout de même un peu rare :

• avoir un form multi-étapes à la main, avec la méthode du core, déclarée à la main
• avoir dedans ses propres champs, avec #SAISIE ou même direct en HTML peu importe
• avoir en plus à un endroit, un appel à #GENERER_SAISIES (donc qui attend un tableau PHP) pour y mettre les champs extras de tel objet, ou en fait tout autre déclaration de saisies en tableau PHP

Alors dans ce cas, ce qui doit être généré par #GENERER_SAISIES est pété puisque ça passe dans tous les mécanismes auto qui prennent en compte $env['_etape'] ou _request('_etape') en essayant de chercher des champs dans une déclaration qui n'existe pas (puisque le form complet lui n'est pas déclaré en saisies PHP).

@b_b a ce cas pour le form de Géodiversité ici par exemple : https://github.com/geodiversite/geodiversite/commit/27e899cc0e71120b0877a0cf71ffa1f1a6077eb5

Et il pointe ces deux commits qui modifient le contenu quand ya "_etape" dans le contexte : https://git.spip.net/spip-contrib-extensions/saisies/commit/34704be534d8f79edb7248eb991ad74071f3895c + https://git.spip.net/spip-contrib-extensions/saisies/commit/608f46deb18ed5e6dc6e09c4821de610002fd7ca

M'est-avis que dans les divers tests il ne faudrait pas QUE tester si ya "_etape", mais aussi si c'est bien un form déclaré en saisies PHP. S'il n'y a pas du tout de "saisies_par_etapes" dans l'environnement, alors il faut laisser tel quel, quelque chose dans ce goût là.