`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

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

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.

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

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

nouveau raccourci pour le message de l'accusé de réception : @message_retour@. Permet de prendre le message standard de retour de formulaire puis de le compléter

options pour ne pas envoyer d'email en cas de modif de réponse (par exemple: lorsqu'on modifie depuis l'espace privé)

Possibilité de définir un texte spécifique pour l'accusé de réception, différent du message de retour du formulaire.

Suite demande de Florence Henry : pouvoir avoir plusieurs champs destinataires comme destinataires des messages

qui est passé au squelette de construction d'accusé de reception.
Par ex pour ajouter automatiquement certains messages en fonction des
résultats.

C'est plus propre que de faire cela par le pipeline recuperer_fond, car
cela ne dépend pas du formatage fait par le squelette.