- Le filtre `|tenter_unserialize` est déprécié.
- Il est remplacé par `|formidable_deserialize`.
- Ce filtre peut recevoir au choix :
  * Un tableau, qu'il retourne tel quel
  * Un tableau serializé via `json_encode`
  * Un tableau serializé via `serialize`
- Dans les deux dernier cas, il renvoie la version deserializé, en cas
de réussite, sinon l'argument passé.

Exemple

````
include_spip('formidable_fonctions');
'filtre');
$a = ['a' => 'a'];

$a = json_encode($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a).'plop';//Serialisation corrompu
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);
````

Ainsi, pas besoin de convertir tous les formulaires de `serialize`  à
`json_encode`  à la mise à jour du plugin formidable :
on peut le faire au fur à mesure qu'on modifie les champs/traitements
d'un formulaire.

On utilisera donc ce filtre à chaque fois que l'on veut déchiffrer
depuis la BDD :
- * traitements d'un formulaire
- * saisies d'un formulaire
- * réponse d'un champ multivalué (ex: checkbox)

Lors de la configuration des champs du formulaire, vérifier à la soumission de l'ensemble des champs si le `@@`  dans les
`afficher_si`  sont cohérents avec les champs du formulaire proposé.

On ne vérifie qu'à la fin, et pas au fur et à mesure, car il se peut
lors de la configuration des champs d'un formulaire qu'on supprime
des champs qui conditionnaient des afficher_si. La vérification
ne peut donc se faire que lors que la liste des champs est ferme.

Nécessite saisies 4.4.0

correction sur c720dccf : pour formulaire_construire_formulaire_champ, passer l'id_formulaire au contexte, sinon ca plante

Ajout de l'option etapes_precedent_suivant_titrer dans les options globales d'un formulaire (cf. saisies#133)

pour gérer le recap final des étapes
- Faire l'appel au bon code de saisies (même si à terme on devrait tout
mutualiser)
- Avoir une option pour ne pas afficher le récapitulatif

de l'affichage des étapes.
- Au lieu d'ajouter des options à chaque fois qu'on veut faire une présentation différente, on propose une seule option globales _etapes_presentation_, qui selon la valeur, va chercher un squelette ou un autre
- Pour l'instant on a :
  - 'defaut' => toutes les étapes, comme c'est le cas actuellement
  - 'courante' => uniquement l'étape courante, et dans ce cas le total
  d'étape (adapté aux éventuels afficher_si)
- On propose cela dans la config globale du formulaire
- On appel le bon modèle

utiliser le paramètre saisie_id plutôt que de le reconstruire après coup. Evite d'avoir une redirection foireuse en cas de suppression de champ (!)

La toute dernière version de saisies (3.47.0) transforme automatiquement
les fieldset des options globales pour ajouter des onglets, dans le
constructeur de formulaire.

option globale pour avoir un afficher_si sur le bouton de validation, cf. https://contrib.spip.net/Formidable-le-generateur-de-formulaires#comment507495

profiter de l'option afficher_si_avec_post des dernières versions de saisies, pour pouvoir tester/retester le multi-étapes

configuration globale du formulaire : cela n'a de sens de pouvoir régler précédent/suivant que si on active le multi etape

uniformisation de la présentation des case dans le formulaire de config des options globale d'un formulaire

systématiquement le cas en base.
Par conséquent les comparatifs de md5 pour vérifier des modifs //
peuvent parfois foirer (PRX38, spipfactory, Nat33 via @marcimat).

On résoud cela en
1. Identifiant retrospectivement les saisies
2. S'assurant avant d'enregistrer en base que les saisies soient bien
identifiées

par définition lorsqu'on fait un revert sur un constructeur de formulaire, on veut revenir aux saisies anciennes, donc inutile de dire qu'il y a eu une différence, ni de faire quels que tests que ce soit de vérification

Il arrivait parfois, lorsqu'on modifiait une saisie d'un formulaire
existant, et qu'on validait la modif des saisies, que formidable nous
disait que le formulaire avait été modifié en base, alors que ce n'était
pas le cas.
Pourquoi cela ?
Parce que le md5 des saisies initiales stocké par le plugin saisies
était faite à partir des saisies passés au squelette.
Or lorsqu'on passe un tableau en contexte de SPIP, celui transforme
tout `integer`en `string`.
Cela posait problème si les yaml indiquait des paramètres par défaut
sous forme d'entier et pas sous forme de string.
En effet le md5 initial était calculé par saisies sur un tableau du type
````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string '40' (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Alors que la vérification par formidable se faisait sur un tableau du
type

````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string 40 (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Forcément les hash n'était pas les mêmes, et cela provoquait une erreur.

Pour éviter cela, on imite le comportement de spip avant de calculer le
hash lors de la vérification: on transforme recursivement dans le
tableau les `integer` en `string`.

sécurité : une fois les saisies stockés en base, les effacer de la session, pour éviter de retrouver des vieilles

issue #9 : lorsque id_revision est passé au formulaire de config de traitement, celle-ci prend le pas sur ce qu'il y en base. Et on passe id_revision à ce formulaire si on l'avait déjà avant

pb #9 : lorsqu'on arrive à la config des champs de formulaire depuis un demande de restauration, prendre les champs de l'ancienne version

- si une personne reprend une veille session alors qu'il y a une modif
en base des champs de formulaire, la veille session est annulée
(correction faite au niveau du plugin saisies
saisies@673fcfac)
- si une personne modifie les saisies et qu'entre le moment où il
commence sa modification et le moment où il valide l'ensemble des
modifs, une tierce personne a modifié en base :
  - on met un message d'erreur
  - on demande de recommencer les modifs, à partir de ce qu'il y a en
  base

Utiliser objet_modifier plutôt que sql_updateq pour générer une révision quand on modifie les traitements ou les saisies.
La restauration de révisions ne fonctionne pas pour autant, mais c'est un autre problème à régler.

option global pour activer de formulaire pour activer la vérification des valeurs acceptables pour les saisies. A voir pour plus tard comment on régle saisie par saisie

Nouvelle fonctionnalité : on utilise toutes les modifs faites en amont sur Saisies. On peut donc maintenant configurer certaines options globales dans l'interface du constructeur. Pour cela on déclare au constructeur quelles options on accepte (c'est propre au contexte de Formidable).

Dans le lot, il y a donc la personnalisation du bouton final, et… le multi-étapes !

Pour cela, il a fallu faire un refactoring de la fonction verifier() de Formidable où tout était en dur… On l'a donc vidé de son contenu, afin que Formidable utilise enfin l'API CVT de Saisies avec la fonction saisies().

Au passsage, il y avait une vérification propre à un traitement (enregistrement) sur l'unicité : on en profite pour mettre en place un fonctionnement générique et extensible. Tout type de traitement peut désormais déclarer une fonction de vérification qui lui est propre avec traiter/montraitement_verifier(). Et si ça existe, ça sera utilisé.

Il reste un problème avec ce dernier point : pour le cas habituel ça continue de marcher pareil MAIS quand on active les étapes… Pour le moment j'ai fait le choix lorsqu'il y a étapes, de lancer ces vérifications propres aux traitements à la toute fin, quand on sait qu'on est à la dernière étape. Mais du coup ça ne va pas, car les erreurs ajoutées peuvent être sur des champs qui sont à d'autres étapes. Et CVT ne le sait pas, il reste sur la dernière étape. Donc ça montre "Vous avez X erreurs" en haut, mais on ne voit pas forcément le ou les champs précis en erreur s'ils sont ailleurs. Je ne sais pas encore comment résoudre ça…

on masque le gros message vert et le gros bouton "Reinitialiser" trop affordants qui sont proposés par saisies.
 A la place un message simple en haut, et le bouton "Revenir à la dernière version enregistrée" dans le cartouche en bas, qui apparaissent dès qu'une saisie est modifiée

- déclarer 'spip_formulaires' en objet éditorial
- renommage des pages exec homogène avec le reste de SPIP : formulaires, formulaire  et formulaire_edit
- décoration des listes de formulaire aux nouvelles normes

Reste à gérer les réponses...

Petit inconvénient aussi, il fait du coup des urls propres pour les formulaires…