Maintain SQLibrary

[TheLimeGlass]

Since SQLibrary doesn't work on latest paper. We can fork it https://github.com/Mitsugaru/SQLibrary (Mitsugaru was the last developer for dakanilabs) and put it on Skript's organization to maintain it until we revamp the entire variable system.

[Moderocky]

I'm concerned about supporting this within the plugin itself - I don't think SQL is the ideal variable storage format or something we should be providing by default since our implementation will always be limited and not as effective as it could be. We're providing for project-makers rather than a project, so we don't know much about how the data is going to end up, meaning our implementation will never be more than average.

I'd like to suggest two things: firstly that variables support more storage options (including ones supplied by external plugins) and secondly that we should export the SQL support to a separate 'official' addon as we plan to do with worldguard.

Supporting it separately would mean we can add actual syntax to this support (e.g. queries, selecting, different SQL database types, etc.) allowing users to make more effective use of SQL that suits their project, IFF they need it. The user knows how their data is arranged so they will be able to design a more effective data model than we can.
This would also reduce the number of third-party, unmaintained dependencies Skript is beholden to.

If we exported the SQL support this would also open the door for adding new storage support types without bloating the plugin, such as NoSQL and flat file formats, and allow addons to make their own.

[TheLimeGlass]

People use MySQL for cross server database. This is something that we cannot get rid of.

Also I added support for external register of databases here for addons when merged #4873