fix : le test d'autorisation de modification de l'objet ne doit pas être appliqué lorsque l'objet en cours est une rubrique mais uniquement si on est dans le cas d'un article.

Fix #9

Un jour il faudra brancher pour utiliser correctement les dernières
version de l'archiviste.

Eviter une erreur fatale en PHP 8.0+ si la fonction exec n'est pas autorisee par php.ini et qi'on a definit _LIBREOFFICE_PATH

Inserer la boite d'import odt en colonne de droite quand on est en SPIP 4+ car sinon la dropzone bigup n'est pas accessible, le formulaire d'ajout de logo prenant toute la colonne de gauche

L'action action_odt2spip_importe() n'est plus utile dans le plugin on la deprecie avec un log pour reperer les cas d'usage a revoir

+ on deplace les icones dans prive/themes/spip/images/ pour pouvoir utiliser #CHEMIN_IMAGE dans l'interface et avoir donc une icone svg quand c'est possible

être certain que les plug ont une version de saisies "sûr", normalement, cela devrait être bon, car aucun n'avait de borne max concernant saisies

[ODT2SPIP] Éviter sur certains hébergements un Warning: exec() has been disabled for security reasons

- Je monte la version de saisie (en gardant la même branche pour réduire le risque de casse) pour être certain que si un jour, un commit qui concerne l'un des plug et saisie, que la version de saisies soit une version sûr !
- + broutilles (exemple, mise en adéquation de borne mini de plug dans les "necessite" avec la version de spip pour quoi le plug est fait)

Après l’importation du fichier odt, le statut de l’article est « en cours de rédaction » et non pas « proposé à l’évaluation ».

Et corrections d’erreurs PHP lorsque le document contient des images dont la taille n’est pas indiquée (peut être du à la conversion doc > odt et la version de libreoffice utilisée pour le faire).

Sur le serveur, /tmp n’est pas toujours accessible pour l’application libreoffice, et notre tmp/odt2spip y fonctionne.
On permet donc simplement de définir _LIBREOFFICE_HOME pour les tests locaux éventuels `define('_LIBREOFFICE_HOME', '/tmp');`

Par précaution, aussi, on nettoie régulièrement le répertoire tmp/odt2spip.

Principe :
* Sur le serveur de conversion (A) : installer un SPIP, libreoffice et activer odt2spip. Créer des clés d’Api nécessaires en configuration.
* Sur un autre site SPIP (B), activer odt2spip, renseigner en configuration l’URL du site spip de conversion, et la clé d’API.

Lorsque le site B charge le formulaire document2spip, il regarde s’il peut convertir les documents,
- soit lui-même (s’il a accès à l’application libreoffice)
- soit via un serveur, si la configuration est renseignée.
- s’il peut, il permet de charger des documents odt, doc(x), html, pdf. Sinon… uniquement odt.

Si un document F non .odt est envoyé à l’API : 
- on le récupère temporairement sur B,
- on le poste à l’api A
- on le stocke sur A temporairement
- on le convertit F' sur A ; on supprime F de A
- on envoie F' à B ; on supprime F'
- on récupère sur B le fichier F', on le stocke temporairement.
- on applique les traitements habituels de odt2spip avec ce fichier.

La seule embrouille possible peut provenir d’un timeout ou d’un gros fichier.
Les traitements se faisant successivement (ce n’est pas le serveur A qui fait un hit sur un callback de B lorsqu’il a fini son traitement ; B attend simplement patiemment),
et le fichier reçu de A n’est pas streamé mais stocké dans une variable. 
C'est surtout ce dernier point qui me semble à améliorer : ie, rediriger le résultat de A directement dans le fichier F' de B en stream.

Pour le reste, ça fonctionne en local. Restera à tester sur un serveur et peaufiner.

- vérifier si 'libreoffice' (la commande) est présente sur le serveur (ou définie par la constante `_LIBREOFFICE_PATH`)
- si oui : on pourra convertir des documents doc, docx sur ce site directement.
- si oui : propose de servir de serveur de conversion en générant des clés d’API acceptées.
- si non : propose d’indiquer une URL et une clé d’API d’un serveur de conversion.

Si la commande 'libreoffice' est dispo, le formulaire 'document2spip' permet de saisir des fichiers
.doc, .docx, .html... qui seront convertis par l’application en .odt.
Note: on ne prend pas en compte encore de serveur distant de conversion à ce point.

Pour l’instant cela fonctionne, en local, sous macOS en déclarant la constante :
`define('_LIBREOFFICE_PATH', '/Applications/LibreOffice.app/Contents/MacOS/soffice');`

L’application a besoin d’écrire dans un répertoire en s’exécutant.
J’ai tenté en vain (en local) de pouvoir utiliser notre répertoire temporaire tmp/libreoffice/{id_auteur}/,
mais les droits ne semblaient pas suffisants. Utiliser `/tmp` fonctionne par contre.

Il faudra voir ce que ça donne sur un serveur.

qui peut prendre en entrée plusieurs types de documents éventuellement
(ie: si un serveur de conversion est indiqué en configuration (mais il faut le faire))

L’idée (à faire) est de pouvoir passer, à terme, des .docx, de les traduire en .odt, 
et de les importer ensuite avec odt2spip comme avant.

- Passage dans des fonctions dédiées de différentes phases qui étaient réalisées dans l’action odt2spip_importe.
- Cette action n’est plus utilisée, mais là pour compatibilité (je n’ai pas testé, mais ça doit être à peu près bon)
- Le formulaire odt2spip devient CVT. Il utilise Saisies. Si Bigup est là, ça le charge au passage (à voir si on garde).