formidable
Plutot qu'avoir
`'[traitements' => ['type_traitement' => ['champ' => ['erreur']]]]`
avoir
`'[traitements][type_traitement][champ]' => 'erreur'` (autrement dit le
nom du champ).

Simplifie considérablement le code de saisies.

fix: ne pas afficher le fieldset d'option des traitements s'il n'y a pas de traitement avec options cochées

fix #150

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

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

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

issue #9 : lorsque id_revision est passé au formulaire de config de traitement, celle-ci prend le pas sur ce qu'il y en base. Et on passe id_revision à ce formulaire si on l'avait déjà avant

Plus de séparation entre les traitements à choisir et leur configuration, moins de marges inutiles, plus d'espace.

Utiliser objet_modifier plutôt que sql_updateq pour générer une révision quand on modifie les traitements ou les saisies.
La restauration de révisions ne fonctionne pas pour autant, mais c'est un autre problème à régler.

Ceci créait une erreur si jamais un champ obligatoire était en
afficher_si et que la condition d'affichage n'était pas rempli.
Et pour cause, on disait de ne pas tenir compte des afficher_si, et de
vérifier tous les champs.

En fait il n'y a jamais eu d'enregistrement dans formidable de la config
des traitements qui ne sont pas activés. Et pour cause : dès lors qu'il
y a une config pour un traitement, celui-ci est considéré comme actif.

Du coup je sais pas ce qui m'a paris de faire r112371.

les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y avait comme env['id'] l'id du formulaire. Ce qui faisait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaitait pas. Pour éviter cela, on précise de quel id on parle lorsqu'on charge le formulaire de config des traitements

conditionné par un afficher_si sont mis à null si la condition n'est pas
validée.

Ce qui veut dire concrètement que si on décoche une case d'un
traitement, toutes les infos sur ce traitement sont perdus. Or on peut
vouloir conserver les réglages d'un traitement sans pour autant
l'appliquer (si jamais on veut rebasculer).

Pour revenir à ce qui était le comportement historique de formidable
(basé sur un bug de saisies), on dit explicitement qu'on ne veut pas de
_request mis à null en cas d'afficher_si.

- déclarer 'spip_formulaires' en objet éditorial
- renommage des pages exec homogène avec le reste de SPIP : formulaires, formulaire  et formulaire_edit
- décoration des listes de formulaire aux nouvelles normes

Reste à gérer les réponses...

Petit inconvénient aussi, il fait du coup des urls propres pour les formulaires…