Database updates and breaking changes in version 2

[A248]

Version 2.0 may not be coming out for a while, but we can use this issue to track database updates and other breaking changes that may need to wait until then.

• Make our own schema management table; keep using libertybans_revision if possible
• Use a single active punishments table, rather than an active table per type, removing the unique type/victim constraint for active punishments (Restructure data: Remove the restriction on unique active punishment per type/victim #316)
• Add ghost mute and potentially custom punishment types ([Feature Request]: Add a ghost mute #238, Change database and API to allow unlimited custom punishment types #308)
• Add notes on existing punishments and/or users, which are not the same as a standalone punishment type ([Feature Request]: Annotate/Note feature  #266)
• May need to store player language in the database, in case it's not available during login ([Feature Request]: Multi-language support #312)
• Create a notifications table to handle warning messages ([Feature Request]: Warning notifications for offline players #303) and ban notices for players who never logged in ([Feature Request]: Send ban notice to player on first join after their ban expires. #232)
• Store scope configuration in the database, and allow multiple scopes per punishment type (Adding scope-related dynamism for the punishment interface #326)

[A248]

Another big change. Rather than having the concept of "victims" and "composite victims," we should switch to a multiple-victim punishment structure. That is, a punishment can have more than one victim, but the same details.

This would allow staff to easily expand or narrow the applicable domain of a punishment. For example, maybe an IP ban should be replaced by a ban on two UUIDs -- that's easily accomplished.

The downside would be increased complexity for API users. Third-party plugins may have to update their assumptions.

public interface Punishment {

  Set<Victim> getAllVictims();

}

[A248]

Still another change. Move the configuration for scope categories from the scope.yml, to the database itself. This will allow the entire network to use the same category definitions without having to copy and paste them for each instance. It will also enable external software to use the same configuration.

[A248]

Allow creating new operator types. The "console operator" can be split up into RCON, regular console, etc. External plugins can create their own operators.

To keep selection simple, operators should still be grouped and queryable by type. For example, get all console- and plugin-related operators.