envoyés.

ref #119

réponse originelle dans le mail

fix #99
close #111

On fait un merge et pas un --ff car ce n'est pas une évolution
anedecotique que ce passage à `json_encode` -> on veut pouvoir bien le
voir dans l'historique.

- 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

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

Complement de e860673d et 7ecaceef pour eviter une erreur à la compilation dans le public quand la fonction statut_titre n'est pas chargée

dans les changelog.

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

`traiter_email_destinataires` : reçois un tableau d'emails (ou une liste
séparée des virgule).
Se complète avec l'option `traiter_email_destinataires_methode_methode`
qui peut être :
- `remplacer` pour que les destinataires passés par squelettes
remplacent ceux de config
- `ajouter` (valeur par défaut) pour qu'ils viennent compléter la liste.

Exemple d'appel

````

 #FORMULAIRE_FORMIDABLE{coordonnees,#ARRAY{input_1,plop}, #ARRAY{traiter_email_destinataires,22@22.fr,traiter_email_destinataires_methode,remplacer}}

````

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.

Fix #108 : meme fix sur le modele <form> + supprimer le test sur la presence du plugin forms qui n'existe plus

+ ajouter un statut==.* pour toujours afficher le formulaire dans l'espace privé, mais avec un .msg-alert.info qui signale que le formulaire est dans un statut autre que publié

[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue de
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue en
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue es
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue fr
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue it
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue nl
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue pt_br
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue ru
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue sk
[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

qu'on ne veut pas, par ailleurs, disposer d'un lien et d'une information
sur "à quel champ correspond les fichiers".

D'autant plus que cette suppression dans le corps du mail ne marchait plus depuis un
certains temps (lorsqu'on a séparer `$saisies` et
`$saisies_notifications`).

En supprimant cette suppression (!), on bugfix le cas où :
- `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` était sur `false`
- mais on disait de mettre les fichiers dans le corps du mail
=> `_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION` à false ne changeait
rien.
Cf. https://discuter.spip.net/t/formulaire-formidable/160827/6

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

lorsqu'une saisie fichiers se trouve dans un fieldset.

Sans oublier les autorisations possibles sur l'affichage d'un formulaire, ou de la liste des formulaires.
En l'état du plugin, les rédacteurs ont accès aux formulaires.

N'afficher que les formulaires dont le statut est publie dans la liste des formulaires qu'on peut acssocier à un objet (article, rbrique...).

cf https://discuter.spip.net/t/formidable-possibilite-de-lier-un-formulaire-avec-status-archive-et-a-la-corbeille-a-un-article-rubrique/160516