l'ajout de réponse.
Note : inutile de d'appliquer cela au changement de statut, car SPIP le
fait pour automatiquement pour le statut de tout objet (cf
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/modifier.php#L261
qui est appeler par objet_modifier, lui-même appelé par objet_instituer)

profiter de la nouvelle version de cvtupload pour permettre de remplacer les fichiers lors d'un envoi de formulaire de modification d'une réponse

et maintenant le cas où on envoie la réponse, mais on l'enregistre pas. On en profite pour mutualiser du code

traitement email, cas simple: les réponses ont déjà été enregistrées. Dans ce cas, on se contente d'ajouter un lien, expirable, pour télécharger le fichier

Indentation

Vérification que les réponses sont bien contenues dans une variable de type tableau et que le nombre d'éléments n'est pas nul

Controle du numero d'id_reponse en base
Mise à jour du champ maj dans la table spip_formulaires_reponses
Vérification de l'id_auteur lorsqu'un id_formulaires_reponses est fourni pour éviter qu'un 
auteur modofie les réponses d'un autre

Changement de méthode d'obtention de l'id_formulaire pour calculé l'id_auteur scrambled. Avant il était toujours vide et c'était seulement l'id_auteur et le mot de passe qui servait au scramble.

- les traitements doivent noter qu'ils ont bien ete executes dans ['traitements'] pour ne pas etre executes plusieurs fois
- un traitement qui veut/doit passer apres un autre peut ne rien faire et rendre la main au premier tour pour laisser l'autre se faire
- on refait la boucle 5 fois au maximum pour executer tous les traitements
- si des traitements n'ont pas pu etre executes, on declenche un mail au webmestre avec l'erreur et un dump de  dans le mail pour ne pas perdre de donnees
- si aucun traitement n'a ete execute (defaut de configuration?) on declenche un mail au webmestre et un dump de  dans le mail pour ne pas perdre de donnees

Cette modification entraine une petite incompatibilite sur les traitements perso : ceux-ci seront executes 5 fois et une erreur sera generee si ils ne sont pas modifies pour renseigner ['traitements']

Securite : toujours utiliser l'id passé en argument de #FORMULAIRE_FORMIDABLE et non celui qui est posté et a pu etre corrompu. On centralise la conversion de l'id en id_formulaire

Extensibilite : fournir id_formulaire et id_formulaires_reponse si possible en sortie de la fonction traiter (pour les pipelines)

puisque le message de retour passe par |propre, inutile de mettre un <br /> devant... cela évite d'avoir un <br /> en début de message

comme le fait remarquer cedric, il n'est pas très poli de ne mettre aucun message après la validation d'un formulaire. Mettons un message par défaut à l'enregistrement en bdd.

pas garder de traces des utilisateurs ayant répondu (tout en gardant
la possibilité d'avoir des réponses uniques, modifiables

* traitement de l'anonymisation. Elle permet de créer des formulaires dont les réponses sont anonymes (pas d'adresse IP, pas de nom de cookie, pas de login)
* export de l'analyse des données en en CSV depuis l'Espace Privé