calculer_voir_reponses : prendre en compte le cas des saisies fichiers, où il faut installer le lien de téléchargement

champs qui n'existeraient pas encore en base pour une réponse donnée.

Partant du constat
1. Que lorsque formidable reçoit une réponse vide (soit par
afficher_si, soit par non remplissage) pour un champ donné, il insère ce
champ en base quand même.
2. Que les seuls cas où le champ non rempli n'est pas présent en base
pour une réponse donnée, c'est quand il a été ajouté dans le formulaire
après l'enregistrement de la réponse.

Il ne paraît pas gênant lorsqu'on appel un crayon sur un champ
inexistant en base pour une réponse donnée de le créer en base, cela
revient juste à faire 1.

crayons sur un champ inexistant en bas car ajouté après coup sur une réponse : trouver correctement la saisie. Reste maintenant à trouver comment enregistrer la réponse en base

les valeurs n'ont pas dans _request() mais dans l'enregistrement d'une
réponse. On peut donc facilement utiliser le raccourci @@ pour afficher
une présentation particulière d'une réponse donnée (cas d'usage : un
plugin perso pour une application métier).

Du coup on fait appel à cette fonction pour affiche_resume_reponse() en
gardant la compatibilité ascendante de ce qui est passé au pipeline
homonyme (dont je doute que qui que ce soit l'utilise, mais c'est une
autre affaire).

oups, lorsqu'on ajoute des arguments à une fonction, fusse-t-elles interne, il faut vérifier tout ses appels

n'était pas une correction de trailing spaces, mais un
changement de casse ! J'ignore diable sur quelle touche j'ai cliqué pour
provoquer cela.
Mea culpa

- suppression d'un code mort sur test de valeur brute ou pas brute,
puisque par défaut renvoyait les deux, le test avait lieu en amont
- pour déterminer la valeur humaine, on se base désormais sur
saisie-vues/xxx, ce qui assure d'avoir une valeur humaine aussi lorsque
c'est prévu mais qu'il n'y a pas d'argument datas à la saisie,
typiquement pour les saisies de type evenements (plugin agenda)

enregistrées correspond au seul traitement "enregistrement".
On déplace donc la config dans les réglages de ce traitement.
La migration des réglages est prévues lors de la mise à jour du plugin.

modifier legerement les paramètres passés à la vue de saisie fichiers, pour ajouter l'url de l'action

Revision de la fonction affiche_resume_reponse introduite par r84737 pour lui faire interpreter les champs.
C'est un peu lourd de passer par saisie pour reformater ensuite le HTML en texte brut mais faisons au plus simple.
On ajoute un pipeline qui permet de faire des petites mises en forme perso sur les champs au besoin (ou sur l'affichage de la reponse).

Les listes de reponses sont par defaut non signifiantes car n'affichant aucune autre information que la date de saisie et l'IP source.
On permet de configurer pour chaque formulaire une chaine qui sera utilisee pour afficher un resume de chaque reponse (les champs @input_1@.. etant remplaces par leur valeur).
Ceci rend les listes de reponse beaucoup plus utilisables.

Une nouvelle balise qui sera peut-être utile à celleux qui veulent afficher leurs réponses enregistrées.

#VOIR_REPONSE{champ} à utiliser dans une boucle (FORMULAIRES_REPONSES).

Par défaut ça afficher la même chose que #VOIR_SAISIE. Mais on peut faire des variantes pour ne sortir que la valeur (en HTML mais sans le label et l'entourage) ou que la valeur brute dans la base.

#VOIR_REPONSE{selection_1, brut}
#VOIR_REPONSE{selection_1, valeur_uniquement}

En troisième argument on peut aussi passer la chaîne qu'on veut afficher pour les champs qui n'ont pas de réponse (champ vide). Sinon c'est le truc par défaut "Sans réponse". On peut y mettre la chaîne vide si on ne veut rien.

- paquet.xml et administration nouvelle mode
- un peu de phpdoc.