Refactoring de Chiffrer en découppant en plus d’éléments

les différentes fonctionnalités. C’est mieux structuré.

- Chiffrement gère chiffrer() / dechiffrer() / keygen() (génération d’une nouvelle clé)
en s’appuyant sur Sodium, toujours présent dans PHP depuis PHP 7.2.
On utilise une chifferement symétrique (comme avec openssl précédement),
mais le code est simplifié car libsodium gère l’authentification du message et son salage.

- Password gère verifier() et hacher() en utilisant password_hash donc,
mais en retirant l’option 'salt' qui n’est plus utilisé par PHP > 8,
et effectivement il vaut mieux ne pas le renseigner (PHP gère un salt tournant
tout seul comme un grand). On s’en sert pour régénerer notre password haché en bdd.

- Cles est un conteneur de clés (tableau nom => clé)

- SpipClés gère les clés SPIP et utilisant Cles. Des fonctions backup() et restore() permettent de lire un backup chiffré

J’ai mis l’attribut `#[\SensitiveParameter]` sur différents paramètres en passant,
il devrait être actif à partir de PHP 8.2 pour dire de ne pas afficher la valeur
dans les affichages de backtrace() par exemple, afin de ne pas divulguer
malencontreusement certaines infos en debug.

Également (Cerdic)

- Sodium exige une cle de chiffrement exactement de la bonne longueur : adapter la cle fournir si besoin (cas du chiffrement du backup des cles avec le pass du user)
- La regeneration des cles ne peut se faire que cle par cle : si on a perdu le fichier des cles, c'est OK de regenerer un secret_du_site a la volee pour pouvoir afficher un formulaire de login par exemple, mais on ne doit surtout pas regenerer un secret_des_auth qui invaliderait tous les mots de passe
- Permettre d'avoir plusieurs instances de SpipCles avec des fichiers de cle differents. Peut etre utile pout les tests unitaires, ou pour faire de l'auth multi-sites (on cherche l'auteur dans plusieurs bases SPIP, chacune associee a un fichier de cle different)