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

null. Les gens savent consciemment s'ils passent une valeur par défaut!

Maintenant, que la richesse des retours de traitement est préservée.
Maintenant, nous pouvons incrémenter y.

Issue 42 : améliorer la liaison des formulaires avec un champ vu comme pour les documents : il FAUT savoir quels liens ont été mis à la main et lesquels sont automatiques suivant les modèles dans les textes. Surtout qu'il y avait un bug : ça virait les liens même ceux mis à la main si on les trouvait pas dans les textes. Maintenant ça fait tout comme les documents : si le form n'est plus en modèles dans les textes, ça passe juste en vu=non, mais le lien reste.

Quand on va chercher les réponses du visiteur en cours, on ne doit pas forcer à ce qu'il ne puisse que re modifier si déjà publié. Si c'était en modération à priori, sa réponse n'est pas validé par un admin mais c'est sa réponse quand même, elle n'est pas à la poubelle, donc il peut continuer de la modifier si on est en option modifiable.

Version Z pour correction des autorisations, qui fait que quand modération à priori, alors quand un visiteur quelconque répond, c'est bien en proposé, pas publié, comme demandé par la config.

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

calculer_voir_reponses : prendre en compte le cas des saisies fichiers, où il faut installer le lien de téléchargement

issue #32 champ date_soumission : déclaration + installation + remplissage avec la date actuelle si on est sur une ancienne version

On profère l'appelation date_soumission à date_reponse car date_reponse
est peu clair, puisque c'est un champ d'un objet _reponse.
date_soumission permet de dire : "là date à laquelle la réponse a été
soumise"

oups

[Formidable] Densifier l'affichage en tenant compte des remarques de Maïeul, Cédric et du define('_SAISIES_AFFICHAGE_COMPACT', 'oui');
La classe .colonincluded permet de ne pas rajouter les " :" (voir commit à suivre sur Saisies)

Respectons le markup standard. Si présentation différente, à faire en
css.
This reverts commit 5d0a7798.

Revertons le bon commit.

J'avais pas reverté le bon commit.
This reverts commit 5fb0d999.

Respectons le markup standard. Si on doit personnaliser, faisons le en
css.
This reverts commit 34b32b0b.

Lors de la réception d'un crayon, utiliser saisies_verifier() pour vérifier la saisie, et pas l'appel direct à verifier_xxx(). Cela permet de tester si la saisie est obligatoire. Fix #31

pipeline formidable_traiter_email_destinataires : passer également  id_formulaires_reponse et id_formulaire

- 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

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

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`.

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

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.