Il n'y a pas/plus besoin de passer par une fonction SQL de normalisation
des dates, puisqu'elles sont normalisées en sql au moment du
stockage en YYYY-MM-DD

Ref https://discuter.spip.net/t/pb-tri-reponses-formidable/168230

fix #136

Le pb est que #129 avait été testé sous SPIP 4.1, mais pas sous SPIP
4.0, qui n'utilise pas les mêmes noms de classe PHP.

Un critère cela genère du code PHP, donc il faut "doublement
guillemeter" les chaînes

fix #134

lorsqu'on exporte le CSV/XLXS

fix #128

SPIP

fix #127

fix(123): Faire fonctionner l'analyse des réponses pour une saisie `choix_grille` lorsque les clés sont numériques.

fix #123

envoyés.

ref #119

réponse originelle dans le mail

- saisies d'un formulaire
- traitements d'un formulaire
- réponse pour un champ multivalué

Sont désormais en json, via
```
$formidable_serialize = charger_fonction('formidable_serialize', 'filtre');
```
C'est un filtre pour faire le sysmétrique à `|formidable_serialize`,
même si en fait on n'a pas vraiment de raison de l'utiliser en filtre.

Sont gardés en serialize_php :
- les paramètres passées en url pour l'action de recup de fichier
- la base du calcul des hash md5 dans les sessions (utilisés pour
s'assurer qu'on ne perd pas des données en cas d'interruption de config
d'un formulaire -> il faut surtout pas rompre la compat).

des traitements deja deserializé, pour ne pas avoir à le deserializé
dans chaque traitement.

- Le filtre `|tenter_unserialize` est déprécié.
- Il est remplacé par `|formidable_deserialize`.
- Ce filtre peut recevoir au choix :
  * Un tableau, qu'il retourne tel quel
  * Un tableau serializé via `json_encode`
  * Un tableau serializé via `serialize`
- Dans les deux dernier cas, il renvoie la version deserializé, en cas
de réussite, sinon l'argument passé.

Exemple

````
include_spip('formidable_fonctions');
'filtre');
$a = ['a' => 'a'];

$a = json_encode($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a);
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);

$a = serialize($a).'plop';//Serialisation corrompu
var_dump($a);

$a = formidable_deserialize($a);
var_dump($a);
````

Ainsi, pas besoin de convertir tous les formulaires de `serialize`  à
`json_encode`  à la mise à jour du plugin formidable :
on peut le faire au fur à mesure qu'on modifie les champs/traitements
d'un formulaire.

On utilisera donc ce filtre à chaque fois que l'on veut déchiffrer
depuis la BDD :
- * traitements d'un formulaire
- * saisies d'un formulaire
- * réponse d'un champ multivalué (ex: checkbox)

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

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

dans les changelog.