Testé avec une utilisatrice externe, ça marche.

formulaires_editer_objet_verifier() ne prend que 3 arguments + retenir correctement l'id_formulaires_reponse

- issue #21 : pouvoir modifier en crayons des champs d'une réponse de
formulaire en tenant compte du type de champ (select, etc.)
- issue #17 : pouvoir modifier les champs extra associés à une réponse

champs qui n'existeraient pas encore en base pour une réponse donnée.

Partant du constat
1. Que lorsque formidable reçoit une réponse vide (soit par
afficher_si, soit par non remplissage) pour un champ donné, il insère ce
champ en base quand même.
2. Que les seuls cas où le champ non rempli n'est pas présent en base
pour une réponse donnée, c'est quand il a été ajouté dans le formulaire
après l'enregistrement de la réponse.

Il ne paraît pas gênant lorsqu'on appel un crayon sur un champ
inexistant en base pour une réponse donnée de le créer en base, cela
revient juste à faire 1.

crayons sur un champ inexistant en bas car ajouté après coup sur une réponse : trouver correctement la saisie. Reste maintenant à trouver comment enregistrer la réponse en base

utiliser les fonctions de recherche natives de saisies, histoire d'être cohérent et de profiter d'éventuelles optimisations

On peut vouloir envoyer un accusé de réception uniquement, sans le mail de notification de base (donc sans destinataire).

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

implode(): Passing glue string after array is deprecated. Swap the parameters

Torsten Willmann a rédigé il y a 5 ans et salvatore a validé il y a 5 ans

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

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

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

fix #8 #9

close #14

des exceptions au niveau des css.
https://zone.spip.net/trac/spip-zone/changeset/65632/spip-zone#file16
On laisse tomber ces exceptions et on utilise le markup SPIP

close #19

Permet d'ajouter automatiquement ses propres destinataires.
Exemple d'usage :
- j'associe via cextras un email aux evenements
- je crée un formulaire formidable avec une saisie evenements
- je notifie automatiquement tout les emails associés aux évenements
choisis par l'internaute

Ne filtrer qu'une seule fois les destinataires des emails pour s'assurer des doublons + appliquer trim par securité

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

utiliser un diff sur yaml plutôt que sur tableau serialisé pour les
saisies et les traitements. C'est plus lisible.

Evidement l'idéal serait de pouvoir construire un vrai système de diff
de tableau, où d'en trouver un existant, mais bon, c'est plus complexe,
et c'est déjà un progrès.

Mais du coup on laisse encore ouvert #13.