Design new data upgrading system that goes along with the new abstract storage interface #22
Description
After #21, the data upgrader system is obsolete given that it is tightly coupled with the bukkit configuration api, which is fine for the BukkitConfigurationStorage, but not for potentially others in the future.
One possible solution is for each storage implementation to have their own data upgrading systems, so the existing one gets renamed and used in the BukkitConfigurationStorage, and when new storage implementations are added, alongside them they implement their own storage upgrading system (e.g. Flyway for SQL). The downside of this approach is repetition of the migration rules, which could lead to improperly copied migrations.
Another potential solution that solves that problem is defining some sort of abstract system for migration rules that is written once, and each storage implementation reads those rules and interprets them on the specific storage domain; it's more abstract, most likely overengineered and not needed, the costs of this approach most likely outweigh the rewards.
For now, this is not a high priority issue given that there is a single storage implementation. That will change when new storage systems are added.