`masquer_champs_vides`.

Cette option a été introduite par moi (!) en
11ad7c44.

J'ai testé en reprenant le code d'alors... et ca ne marchait déjà pas.

En fait je ne vois pas comment cela aurait pu marcher, puisque saisie
affiche `Sans réponse` si aucune valeur n'est passé pour une saisie.

Ce sont bien les saisies qu'il faut filtrer, pas les valeurs.

fix #147

- saisies d'un formulaire
- traitements d'un formulaire
- réponse pour un champ multivalué

Sont désormais en json, via
```
$formidable_serialize = charger_fonction('formidable_serialize', 'filtre');
```
C'est un filtre pour faire le sysmétrique à `|formidable_serialize`,
même si en fait on n'a pas vraiment de raison de l'utiliser en filtre.

Sont gardés en serialize_php :
- les paramètres passées en url pour l'action de recup de fichier
- la base du calcul des hash md5 dans les sessions (utilisés pour
s'assurer qu'on ne perd pas des données en cas d'interruption de config
d'un formulaire -> il faut surtout pas rompre la compat).

des traitements deja deserializé, pour ne pas avoir à le deserializé
dans chaque traitement.

uniquement par le plugin `formidable_quizz`, actuellement non maintenu
et non publié.

Ce pipeline n'était pas générique, car le remplacement des `@@` ne
concerne pas que l'affichage résumé des réponses, mais aussi en
différent endroit (message de retour par exemple).

On créé deux pipelines plus générique :
- `formidable_pre_raccourcis_arobases`
- `formidable_post_raccourcis_arobases`

On supprime donc le pipeline `formidable_affiche_resume_reponse`.

On simplifie par ailleurs la signature de la fonction
`formidable_raccourcis_arobases_2_valeurs_champs()`.
1. En supprimant les deux derniers arguments passés par références (`$valeurs` et
`$valeurs_libellees`).
La seule raison de ce passage par référence, qui n'était utilisé sur
toute la zone que dans **UN** appel à la fonction, était précisement
de passer les valeurs libellées en arguments du pipeline `formidable_affiche_resume_reponse`. Puisqu'on supprime ce pipeline, plus besoin de ces valeurs.
2. On regroupe tout les paramètres en troisième arguments, dans
$options, tout en assurant une rétrocompatibilité (pas d'autre usage de
`formidable_raccourcis_arobases_2_valeurs_champs()` sur la zone, mais j'ai
du code perso qui l'utilise, et il n'est pas impossible que d'autres
fassent de même.
3. On ajoute une option `'contexte'` pour indiquer le contexte d'appel
de `formidable_raccourcis_arobases_2_valeurs_champs`, ce qui permet de
remplacer utilement le pipeline `formidable_affiche_resume_reponse`.

`traiter_email_destinataires` : reçois un tableau d'emails (ou une liste
séparée des virgule).
Se complète avec l'option `traiter_email_destinataires_methode_methode`
qui peut être :
- `remplacer` pour que les destinataires passés par squelettes
remplacent ceux de config
- `ajouter` (valeur par défaut) pour qu'ils viennent compléter la liste.

Exemple d'appel

````

 #FORMULAIRE_FORMIDABLE{coordonnees,#ARRAY{input_1,plop}, #ARRAY{traiter_email_destinataires,22@22.fr,traiter_email_destinataires_methode,remplacer}}

````

qu'on ne veut pas, par ailleurs, disposer d'un lien et d'une information
sur "à quel champ correspond les fichiers".

D'autant plus que cette suppression dans le corps du mail ne marchait plus depuis un
certains temps (lorsqu'on a séparer `$saisies` et
`$saisies_notifications`).

En supprimant cette suppression (!), on bugfix le cas où :
- `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` était sur `false`
- mais on disait de mettre les fichiers dans le corps du mail
=> `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` à false ne changeait
rien.
Cf. https://discuter.spip.net/t/formulaire-formidable/160827/6

lorsqu'une saisie fichiers se trouve dans un fieldset.

Voir saisies#142 pour l'historique

Réparer la vérification d'unicité d'un champ en mode multi-étapes : l'index du tableau des étapes n'est pas un entier, mais une chaine 'etape_X'

(cherry picked from commit 75ffd233)

Recupération des fichiers par email : passer les args en base64 histoire de ne pas avoir de surprise en case de fichier avec des noms tordus. Merci @nicod_ pour m'avoir aiguiller sur le problème des noms pour ce bug qui courait depuis longtemps.

Sauf pour les importes depuis f&t, vu que tjr en .yaml + chaine de
langue + maintien compat historique

On en profite pour passer systématiquement datas à `saises_chaine2tableau()`, afin
de profiter systématiquement de `_T_ou_typo()` (même si en l'occurence,
ca passait deja tout le temps, on ne sait jamais pour l'avenir si on
stocke autrement les saisies de formidable...)

décide s'il affiche ou pas son message spécifique, en connaissant par
ailleur le message general.

Up de y.
Fix #58 (again !)

maintenant que le formulaire s'occupe lui même de concatener les messages_ok, on peut s'épargner ces 2 tests

automatiquement, il faut que les @@ soit interprétés partout ailleurs
(coprs du message, en tete, sujet, etc).

hop @rastapopoulos

en faisant de l'archéologie dans la doc de de formidable, j'ai suis tombé sur https://contrib.spip.net/ecrire/?exec=article&id_article=3486

j'ai vu que prévoyais au départ une fonction `update` pour les traitements. Et de facto cette fonction existait pour le traitement enregistrement.

Mais par ailleurs il n'y a aucun appel à cette fonction dans le code. De plus il me semble que c'est piégeux, car ca risque de demultiplier le code. Comme par ailleurs j'avais moi même ajouté `$retours['modification_reponse'] = true` au retour du traitement enregistrer, permettant aux traitements ultérieurs d'avoir l'info, je ne vois pas la logique de cette fonction distincte.

Je supprime donc.

date_soumission devient date_envoi, plus proche du langage courant, tout
en évitant de confondre avec date_reponse qui pourrait être la date de
l'objet.
On fait pas de migration de structure SQL car il s'agissait d'une branche de dev qui n'a existait que 24h et n'a a priori été déployé que chez le dev.

bonus: pouvoir suffixer automatiquement les sujets d'email avec [Modification d'une réponse], si pertinent

issue #33 : modifier l'entête d'email pour indiquer la date de la précédente réponse en cas de modif

pipeline formidable_traiter_email_destinataires : passer également  id_formulaires_reponse et id_formulaire

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

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é

oups, dans la config d'un traitement, une case décochée a bien une valeur enregistré en base (''), donc faut modifier le test

effacer TOUT les anciens résultats, et pas uniquement pour les champs
qui viennent d'être postés.
En effet, les nouvelles valeurs peuvent conditionner le non-affichage
d'un champ pour laquelle une valeur avait été enregistrée avant. Dans ce
cas il faut aussi effacer cette valeur.
Exemple
- Le formulaire est configuré de sorte que si la case_1 est cochée, alors afficher le champ input_1.
- Premier enregistrement de la réponse : case_1 cochée, champ input_1
valant 'toto'
- Modification de la réponse : case_1 décochée.
  - Avant ce commit, la valeur 'toto' restait associée à case_1 en base,
  faussant tableau d'analyse et autre
  - après ce commit, ce n'est plus le cas