On affiche l'objet auquel il est lié, les valeurs brutes saisies, puis un aperçu visuel du block

Et classer `{par rang, titre}` par défaut

C'est une fonctionnalité trop spécifique qui alourdit l'UI

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

- création d'une table de liaisons blocktype -> blocktype, avec un role [parent|enfant]
- mise à jour des rôles sur la page d'édition d'un blocktype et contrainte d'intégrité (si un blocktype A ne peut être contenu que dans un blocktype B, alors le blocktype B peut forcément contenir le blocktype A)
- chaines de langue

Un champ objets sur les types de blocs, pour restreindre un type de bloc à un ou plusieurs objets éditoriaux

Ajout d'un identifiant qui servira à trouver le squelette qui affiche chaque type de bloc (blocks/identifiant.html ou blocks_prive/identifiant.html)

Commit initial en sortie de la fabrique