Lors de la configuration des champs du formulaire, vérifier à la soumission de l'ensemble des champs si le `@@`  dans les
`afficher_si`  sont cohérents avec les champs du formulaire proposé.

On ne vérifie qu'à la fin, et pas au fur et à mesure, car il se peut
lors de la configuration des champs d'un formulaire qu'on supprime
des champs qui conditionnaient des afficher_si. La vérification
ne peut donc se faire que lors que la liste des champs est ferme.

Nécessite saisies 4.4.0

correction sur c720dccf : pour formulaire_construire_formulaire_champ, passer l'id_formulaire au contexte, sinon ca plante

retombait sur un formulaire de config de traitement vierge
(`exec=formulaire_edit&configurer=traitement`), ou plus exactement au formulaire de création d'un nouveau formulaire.

C'est parce
que l'identifiant du formulaire formidable n'était pas envoyé lors de le
soumission du formulaire de config des traitements. Or lorsque
`?exec=formulaire_edit` ne reçoit pas d'`id_formulaire`, il affiche le
formulaire de création de formulaire formidable.

On corrige en passant le `id_formulaire` en `POST`.

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

formulaire lorsqu'on l'appel dans un squelette.
Pour ce faire, on modifie la syntaxe de `#FORMULAIRE_FORMIDABLE`, qui ne
prend désormais plus que trois arguments
- id nunérique ou identifiant textuel du formulaire
- tableau de valeur par défaut
- tableau d'options
On assure la retrocompatibilité, car il y a beaucoup de gens pour qui le
troisième paramètre c'est l'id de réponse.

Attention, pour l'heure on ne peut pas le faire dans un contenu, car il
n'y pas de syntaxe SPIP pour passer des tableaux en options de formulaire.

Ajout de l'option etapes_precedent_suivant_titrer dans les options globales d'un formulaire (cf. saisies#133)

"Valider" et non pas "Enregistrer".

Surchargeable par option globale du formulaire.

Cf saisies#120

Non, il y avait aussi la possibilité de surcharger formulaire par
formulaire.
This reverts commit d3028b02.

historique, on la vire donc vu qu'on casse.

tcharlss a rédigé 3 years ago et Maïeul a validé 3 years ago

* Nouvelles icônes en partie basées sur le set ikonate.
  * On les déplace dans le dossier du thème, sinon certains filtres ne les trouvent ps (icone_horizontale, etc.)
  * Nouvelle icône pour les formulaires
  * Pour les autres on part sur du symbolique, pas besoin de reprendre l'icône du formulaire à chaque fois en fond.
    + Suppression du thème basic
    + Renommage et suppression de quelques icônes inutilisées
* Ajustement divers de boutons

pour gérer le recap final des étapes
- Faire l'appel au bon code de saisies (même si à terme on devrait tout
mutualiser)
- Avoir une option pour ne pas afficher le récapitulatif

de l'affichage des étapes.
- Au lieu d'ajouter des options à chaque fois qu'on veut faire une présentation différente, on propose une seule option globales _etapes_presentation_, qui selon la valeur, va chercher un squelette ou un autre
- Pour l'instant on a :
  - 'defaut' => toutes les étapes, comme c'est le cas actuellement
  - 'courante' => uniquement l'étape courante, et dans ce cas le total
  d'étape (adapté aux éventuels afficher_si)
- On propose cela dans la config globale du formulaire
- On appel le bon modèle

afficher_si entre les étapes ou pour conditionner des étapes :
- Adaptation à la nouvelle gestion des étapes dans saisies

les dernières versions de la normalisation de date normalisent les dates vides à 0000-00-00, en tenir compte pour les dates d'export

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

saisies masquées par afficher_si. Lors de l'enregistrement des réponses
d'un formulaire, on cherche les saisies qui ont masquées et ont les mets
à `null`.

perf sur export csv : plutot que de parcourir les réponses pour vider les IP, ne les inserer au moment où l'on prépare les lignes que si on les demande explicitement

Message de DD sur contrib : si pas d'export des IP lors de l'export des réponses, ne pas mettre l'entete correspond