On rend l'include global

Tester l'existence des tables avant de les supprimer
Supprimer aussi les données de spip_auteurs_liens

* les balises, dans blocks_fonctions.php
* les utilitaires, dans inc/blocks.php

et DODO 

On verra plus tard pour en mettre dans un autre

(oué, je fais un lot, je fatigue là...)

Un squelette vide, et la bonne déclaration cvt

On supprime le statut prop, doublon de prepa fonctionnellement
On ajoute le statut poubelle, et on branche la corbeille

On ne se base plus sur le constructeur de formulaires et un objet éditorial `blocktype`, mais sur des fichiers de config en .yaml, à l'instar des modèles gérés par inserer_modeles
Cela implique donc de la suppression de code et de fichiers (toute la gestion des objets `blocktype`) et de nouvelles fonctions pour gérer proprement des fichiers de config.
La fonction principale `blocktypes_lister_types` met tout ça en cache pour le hit (en static), et des fonctions utilitaires viennent taper dans ce cache.

Il y a une procédure de migration (cf README.md), qui sera peut être déportée dans un deuxième plugin à part dans lequel je mettrai aussi des démos de blocks de base, pour alléger le code et les fichiers de celui ci.

Restent à traiter les notions de block conteneur, et les contraintes parent/enfant, ne peut contenir que / être contenu que dans.
Et une todo list qui s'allonge...

Les blocktypes ne sont plus gérés dans le privé avec une table dédiée et un constructeur de formulaires, mais se basent sur des fichiers blocks/*.yaml (comme saisies, compositions, inserer_modele etc.)
Une procédure de mise à jour / migration est prévue, cf README.md

fix: Les `.objetblock` ne sont pas forcément les enfants directs de `.sortable`, on ne peut pas utiliser `this.toArray();`

Utiliser le bon nom de classe

La fonction principale _block_charger_block va récupérer elle même les squelettes des blocks enfants si le block en a.
Si on est dans l'espace privé, on inclut `prive/squelettes/inclure/block_objet` qui contient tout ce qu'il faut pour gérer un block (boutons etc), sinon on charge simplement `inclure/block` du squelette public.
Gros avantage pour l'intégration : dans le squelette d'un block qui peut contenir des blocs, on peut placer un `<!--blocks-->` qui sera remplacé par les blocks enfants, et donc on peut les encapsuler dans un markup personnalisé.

Quand on modifie en ajax, l'id_block revient dans l'url de la page courante et peut provoquer des conflits

Ref #10

Ref #10