lorsqu'on exporte le CSV/XLXS

fix #128

SPIP

fix #127

envoyés.

ref #119

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

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

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

`formidable_verifier_reponse_formulaire()` devait retourner un tableau
contenant les id des réponses.

et que cette saisie est masquée par afficher_si.

puisqu'on s'était permis de casser la compat 3.0 en 133811c1, pour
utiliser `recuperer_url`, autant l'utiliser tout le temps (fix warning,
et moins de trafic reseau).

Recupération des fichiers par email : passer les args en base64 histoire de ne pas avoir de surprise en case de fichier avec des noms tordus. Merci @nicod_ pour m'avoir aiguiller sur le problème des noms pour ce bug qui courait depuis longtemps.

fix #65, stocker en base le nom du fichier tel que sur le disque, selon les renommages éventuels de SPIP

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

`formidable_raccourcis_arobases_2_valeurs_champs` pour les formulaires
avec des fieldsets et des explications.

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

Evitons de donner le même nom à la variable qu'on veut retourner et à
celle qui sert de réceptacle à preg_match(), sinon on peut renvoyer en
cas de nom match un tableau array(array(empty)) ce qui n'est pas le
souhait.

remplacement des @@ : s'assurer de ne pas avoir des espaces trainants dans les champs, notamment si on fait (@truc@)

Quand on va chercher les réponses du visiteur en cours, on ne doit pas forcer à ce qu'il ne puisse que re modifier si déjà publié. Si c'était en modération à priori, sa réponse n'est pas validé par un admin mais c'est sa réponse quand même, elle n'est pas à la poubelle, donc il peut continuer de la modifier si on est en option modifiable.

implode(): Passing glue string after array is deprecated. Swap the parameters

Il arrivait parfois, lorsqu'on modifiait une saisie d'un formulaire
existant, et qu'on validait la modif des saisies, que formidable nous
disait que le formulaire avait été modifié en base, alors que ce n'était
pas le cas.
Pourquoi cela ?
Parce que le md5 des saisies initiales stocké par le plugin saisies
était faite à partir des saisies passés au squelette.
Or lorsqu'on passe un tableau en contexte de SPIP, celui transforme
tout `integer`en `string`.
Cela posait problème si les yaml indiquait des paramètres par défaut
sous forme d'entier et pas sous forme de string.
En effet le md5 initial était calculé par saisies sur un tableau du type
````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string '40' (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Alors que la vérification par formidable se faisait sur un tableau du
type

````
0 =>
    array (size=4)
      'options' =>
        array (size=4)
          'type' => string 'text' (length=4)
          'size' => string 40 (length=2)
          'autocomplete' => string 'defaut' (length=6)
          'nom' => string 'email_1' (length=7)
      'verifier' =>
        array (size=2)
          'type' => string 'email' (length=5)
          'options' =>
            array (size=1)
              ...
      'identifiant' => string '@5e5bed05e689c' (length=14)
      'saisie' => string 'email' (length=5)
````
Forcément les hash n'était pas les mêmes, et cela provoquait une erreur.

Pour éviter cela, on imite le comportement de spip avant de calculer le
hash lors de la vérification: on transforme recursivement dans le
tableau les `integer` en `string`.

SPIP 3.0 n'est plus supporté. On passe donc en compat spip 3.1 minimum , ce qui permet d'utiliser recuperer_url, de faire une requete HEAD plutot que GET, pour vérifier que le fichier est inaccessible

nouveau raccourci pour le message de l'accusé de réception : @message_retour@. Permet de prendre le message standard de retour de formulaire puis de le compléter

c1baaee2 était un peu trop fort. En effet, si jamais on a un identification par id_auteur sans anonymisation, alors la variable PHP peut être pertinente

Amélioration de l'anonymisation dans le cadre une d'identification par identifiant de la personne identifiée. Modification légère de la base.

Possibilité d'utiliser une méthode d'identification par l'identifiant de la personne identifiée tout en anonymisant les réponses.

si on veut la forme brut d'un saisie qui renvoie un tableau, transformer correctement ce tableau avant