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.

On mutualise le code (ce qui en plus rend plus lisible la fonction de
traitement des emails)

Dans le cas où on a affaire à un tableau de valeur, on parse le tout et
on met une virgule comme séparateur.
Eviter de tester un isset() sur un tableau.

- un trim pour éviter les soucis d'espace entre / avant les virgules
- on autorise la syntaxe classique avec les @

les valeurs interprétées et pas les valeur brutes.
Dans certains cas on a besoin des valeurs brutes. On met une case qui
permet de le faire.

Un isset pour pas avoir de warning si clé pas existante. + un changement de nom de variable + des commentaires pour comprendre

(pour les optgroup).
Par conséquent, pour récupérer le résultat textuel, il faut aplatir au
préalable le tableau de description.