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