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

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

Amélioration de l'anonymisation dans le cadre une d'identification par identifiant de la personne identifiée. Modification légère de la base.

Possibilité d'utiliser une méthode d'identification par l'identifiant de la personne identifiée tout en anonymisant les réponses.

Modification d'une réponse depuis l'espace privé : le faire même si le formulaire n'autorise pas la modification par les utilisateurs de leurs propres réponses

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

lors de l'enregistrement d'une réponse, indiquer dans la chaine de traitement s'il s'agit d'une modif d'une reponse, pour que les les traitements ultérieures puissent, le cas échéant, avoir un comportement spécifique

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

méthode d'identification de la réponse à éditer : par passage explicite
de l'identifiant, sans tenir compte ni du cookie, ni de l'id_auteur.

La conséquence concrète de ce bug était perverses et peu visible. Dans
les cas où un formulaire était soumis avec un fichier, mais qu'il y
avait une erreur au premier envoi, lors du second envoi on avait une
erreur mysql de type duplicate entry, et, conséquence étrange, la saisie
immédiatement après la saisie fichiers n'était pas enregistré en base.