Configloader Rework

[Gregor7008]

Implementation of background system to, if config files are changed whilst the bot is operating, update all the old configuration files without the bot breaking.
Could be done by saving all the old keys and value-data-types, trying to get the updated versions and on an error update the config files whilst returning castet values so it matches the updated system for now.

[Gregor7008]

Simple concept:

1. Save example config file with default values
2. Add xml or json file for declaration of changes
3. If Configloader throws error because key wasn't found, check config completely and enforce all changes declared in file from 2.

Edit 1: I added a DataNotFoundException in the most recent commit which will be thrown, whenever such a "key not found" error occurs. Didn't implement it yet and will not until the whole rework is done, but it's here to stay - maybe. I might also add a simple static "version" key to every class implementing DataContainer, that will result in a check being run on every data file containing a version string that doesnt match the currently defined version string within the class file...

[Gregor7008]

Moved to V3 as this will be done with a complete makeover of the configuration file system.

[Gregor7008]

Moved to V2 once again, as this ConfigLoader Rework is needed so badly - Just look at the new ModMail system that was implemented in V2 and how simple it would have looked if the ConfigLoader wouldnt just return JSONObjects but full qualified DataObjects specified for the type of data they contain...

[Gregor7008]

Quick update on what still has to be done:

• Implementation of the 'GiveawayData.class' including any message building and interaction management
• Transfer of the J2C-Tool functions from 'EventProcessor.class' to the 'Join2CreateChannelData.class'
• Implementation of the '.buildEndEmbed()' function in 'PollData.class'
• Implementation of the 'ReactionRoleData.class'
• Implementation of the 'WarningData.class' including a notification to the 'ModController.class' whenever one is added
• Adaption of said 'ModController.class' to a new event based system instead of the old 5-minute-check-cycle system
• Merging of the old 'ConfigLoader.class' and the 'ConfigManager.class' to a 'DataLoader.class'
• Adaption of Butler George to the new 'DataLoader.class'

Yes, it doesn't only seem like it's a lot, but I thought I might put an update here - also just to calm myself down 😅!

[Gregor7008]

Alright, I got bad news: I think we have to code everything again, as data should be stored in ID form and not in some member object, that might become invalid over time. Imagine this: We save a members java object on configuration, this member deletes his account and we try to interact with that saved java object: I do not want to imagine what would happen, if this would happen so we gotta prevent it, by switching to IDs and retrieving the user/member/guild/channel/message every time we need the object. This would happen within the data classes still, but it means rewriting of already completed code...