Journaliser les evenements sur un abonnement + refactor de la desactivation (partie 2 de #18)

(Cette PR est la suite de #21 et repose dessus)

Deux choses dans cette PR (mais qui sont liées) :

• un champ log pour garder une trace des actions sur un abonnement (creation, activation, desactivation...), qui a demandé cette action et éventuellement pourquoi. On a aussi des fonctions utilitaires pour peupler facilement ce log, et on les appelle aux endroits stratégiques
• une gestion revue de la desactivation :
  • au lieu de programmer un job de desactivation pour chaque abonnement, dans le futur, ce qui peut très vite surpeupler la queue de SPIP si on a des milliers d'abonnements en cours, on ne programme un job de desactivation que pour les abonnements finissant dans les prochaines 48h, pour rester précis, et le genie de surveillance se charge de programmer ces jobs au fur et à mesure
  • on permet d'indiquer une raison de la desactivation, à travers la chaine de demande

Par ailleurs on evite de programmer puis deprogrammer une tache de desactivation pour un abonnement dont on change à la fois la date de fin et le statut, ce qui était un petit glitch pas très heureux au moment où l'on passe un abonnement en résilié en changeant sa date de fin à "maintenant" par exemple...