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

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

pas été créé lors de l'installation.

Si on se base sur alea_ephemere (qui change régulièrement) pour générer le hash qui permet de récupérer les fichiers, les liens envoyés par mail ne fonctionnent plus. On crée donc un hash spécifique 'secret_de_formidable' de la même façon que le 'secret_du_site', qu'on n'utilise pas pour ne pas l'exposer inutilement.
Fix #77

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

tcharlss a rédigé il y a 3 ans et Maïeul a validé il y a 3 ans

* 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

La version 5.y de Formidable concernera SPIP 4.y.

Du coup elle s'appuie forcément sur Saisies 4.y.

Ceci a pour but de mieux profiter des futures évolutions des markups
des saisies `radio`/`checkbox` (passage en `<fieldset>`), sur lesquels `champ` s'appuie.

vieilles versions de PHP... alors que c'était bien une grosse faute de
syntaxe.

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

formulaire.
Mais un slug ne peut pour l'heure pas contenir des majuscules.
Pour éviter de force la main aux gens (au risque de casser l'existant),
on rétabli pour l'instant l'ancienne verif en regex.
A voir comment on fait à moyen terme dans le ticket #60

utiliser le paramètre saisie_id plutôt que de le reconstruire après coup. Evite d'avoir une redirection foireuse en cas de suppression de champ (!)

décide s'il affiche ou pas son message spécifique, en connaissant par
ailleur le message general.

Up de y.
Fix #58 (again !)

Puisque maintenant le javascript est à part, on peut mettre une case à
cocher pour demander d'afficher explicitement les messages de retour de chaque
traitement si jamais on a défini un message général.

allons y carrément : formulaire/editer_formulaire.html est vide, et c'est saisies qui s'occupe de tout (mais pas encore pour le chargement des valeurs)

deleguer à saisies la verification de formulaire_editer_formulaire (y compris slug, avec la dernière version de slugify