feat(storage): groups storage layer

[Manason]

In This PR

• Introduces a storage layer of predefined SQL queries for interacting with the groups and group_grades tables
• Moved data model for groups into the storage layer
• renamed existing storage layer to players.lua and moved into a newly created storage folder

Design for the dynamic groups system (future PRs):

Goal: Support changing attributes of groups at runtime. This supports features such as bosses adjusting employee pay, police departments adding/removing ranks, governments adding jobs, etc.

On Server Initialization (Getting data into the database from configs)

The database will become the source of truth for group data. On server load, all groups will be fetched. This is the only time the database is read from. This is merged with the jobs & gangs config to form the jobs and gangs tables that will be stored in core and returned by exports and the bridge core object. The merging logic will completely overwrite any groups that are in the config and also the database. It will not interleave or attempt to merge at the grade level. So if a group is in the database and in the config, only the databases data will be used. This is done on server init so that we can assume that all groups are in the database. Without this assumption, we would have to check on every modification for existence of groups.

After the merge, any groups in config and not in the database and inserted into the database.

Updating Data Dynamically

Updates to the data will update the core cache directly and do an immediate write to the database. A set of commands with an ace permission of 'qbx.group_manager' will allow for dynamic modification of the data by admins. Additionally it would be nice to provide a menu for easier editing. New exports will be added for other scripts to call to modify the data. Database functions will not be directly exposed to other resources, and it is expected that other resources will not directly modify or access the group tables owned by core.