Changement de stratégie assez important pour le coup, et notamment pour séparer un peu certaines fonctions JS
qui pourraient être génériques dans SPIP.

A) On sépare le JS de bigup pour clarifier et minimiser la partie compilée par SPIP :

1) le fichier bigup.utils.js déclare des fonctions génériques, notamment
un objet `Traductions` qu’on instancie dans une variable globale `Trads`.
Cet objet permet d’obtenir, à partir d’un nom de clé et module, une traduction qui y aurait été déclaré.
Note: ça ne gère pas de langue actuellement, en supposant que le texte contenu est dans la langue de l’utilisateur,
mais on pourrait éventuellement être plus précis dans le futur.
Trads dispose de fonctions tel que `Trads.traduire('module:cle')` ou `Trads.singulier_ou_pluriel(nb, 'module:singulier', 'module:pluriel')`,
dont la signature est comme on l’imagine, l’équivalent de ces fonctions en PHP.
On déclare d’ailleurs une fonction _T() alias de Trads.traduire(), qui est utilisée dans bigup.js ensuite.

2) le fichier bigup.trads.js.html déclare les traductions de bigup (et aussi 'unites') à l’objet Trads, dans une certaine langue.

3) bigup.js déclare la classe Bigup et quelques fonctions pour bigup, mais n’instancie pas la classe.

4) bigup.loader.js instancie où on le souhaite le script bigup, en l’occurrence, comme avant, sur tout input file
ayant la classe .bigup, dans un formulaire SPIP.

5) on déclare la configuration JS de bigup directement dans le pipeline insert_head, de sorte qu’elle ne soit pas en cache.
Et on adapte les chargements des pipelines en conséquence.