🧱 feat(config): Réécriture de la configuration

[ascpial]

Cette PR a pour but d'écrire un nouveau système de configuration pour être à la fois plus simple pour débuter et plus puissant avec une utilisation avancée.

Le fichier affecté pour le moment par la réécriture est indépendant du reste du projet.
Je commencerais à modifier les plugins pour fonctionner avec ce système quand il sera mature.

Pour voir l'état actuel de l'écriture du nouveau système de configuration, vous pouvez aller voir l'exemple contenu à la fin du fichier bot/config.py.

Je met ici ce qu'il est possible de faire avec le système mais je ne garantie pas qu'il sera à jour :

# géré par le cœur, qui charge les fichiers comme il veut
# le développeur de plugin doit ne pas avoir à toucher à ces initialisations
config1 = Configuration(is_child=False)
config1.load("test.yaml")

# si le développeur a vraiment la flemme mais une flemme paradoxale, il
# peut accéder à la configuration comme ceci
print(config1["ban"]["friendly_ban"])

# cette partie est le minimum syndicale pour le développeur
ban_config_1 = Configuration(namespace="ban")
config1.add_configuration_child(ban_config_1)

# à partir de là le développeur peut accéder à la configuration comme suit
print(ban_config_1['friendly_ban'])
# on est d'accord que c'est plus propre que ce qui est affiché plus haut

# nouvelle exemple

config2 = Configuration(is_child=False)
config2.load("test.yaml")

# le développeur de plugin peut aussi ajouter les champs en tant que variable
class BanConfiguration(Configuration):
    friendly_ban = ConfigurationField(bool) # on pourra définir le type, avoir une conversion des données, mettre une valeur par défaut etc à terme

# les mêmes étapes que plus haut (le *minimum syndical*)
ban_config_2 = BanConfiguration("ban")
config2.add_configuration_child(ban_config_2)

# et pouf ça fait des chocapic
print(ban_config_2.friendly_ban)
# encore plus propre que plus haut non ?
# et ça supporte le typage avec par ex vscode ! (si tu spécifie un type)