Add Parties Feature

[Silvager]

This PR adds parties-allowing a group of players to choose to be on the same team.

How parties work:
Parties are just groups of players. There is no party leader.
You can create a party with someone by typing "/party invite {player name}". If they accept by typing "/party accept {your name}", both players will now be in a party together.
If either of those players sends invitations to additional players, those players will join the same party as well.
You can leave your party by typing "/party leave". You will also leave if you disconnect from the server.
If you disconnect, all pending invitations sent to you, or invitations sent by you, will be deleted.
You can check if you are in a party or not, who is in your party, and what incoming or outgoing invitations you have by typing "/party info".
Parties that are too large will be disbanded. You can set the max party size in minetest.conf using the field ctf.max_party_size.
Additionally, parties will be disbanded if they are larger than the team size that round. For example, if the max party size is set to three, but there are only 4 players online, the party will be disbanded because (if it's a two-team map) the size of each team is 2.
Players are unable to invite players to their party if the party is at max party size. Players also cannot accept invites from parties at max party size. (A valid invite to a party already a max party size could happen if a player a invites player b to a party, then joins player c's party. Player c's party is now at max size, but the invite from player b is still valid. In this case if player b accepts, they are still unable to join).
Party sizes are also checked at the start of each new round. This is because a player could be in a party with an acceptable size for a two-team map, but on a four-team map the party will be disbanded because there are too many players for the new team size. Also, if a party is made when there are many players online, and then a bunch leave, the party might be disbanded for being over the team size.

Parties are allocated to teams at the start of each round, before the non-party players. Parties do not take effect immediately. The players in each party are all assigned to the same team at the start of the next match.
Parties are allocated based on a modified version of the player allocation function in features.lua. This means that parties are more likely to end up on a smaller or weaker team. And a game with multiple parties will most likely assign multiple parties to different teams and try to keep the number of party-players on each team as equal as possible without splitting up parties.
The rest of the non-party players will then be passed normally through the team allocation pipeline.

What is changed:
Most of the additions are in ctf_teams/parties.lua but there are a few changes in ctf_teams/functions.lua.
There is also something added to ctf_parties/init.lua to run a function to delete players from parties when they leave the game.

Notes:

• Teams will not be balanced if parties are present and the default team allocator written in ctf_teams/functions.lua is used. This is because that algorithm assigns player to a random team regardless of any party players present.
  This is not really a problem because no modes actually use this default allocator. Everything uses the advanced allocator in ctf_modebase/features.lua team_allocator. The advanced allocator is able to handle the presence of parties well.
  So parties would only be unbalanced if a new mode was added and the creator forgot to set the team allocator to the advanced allocator.
  What I would propose is that at some point just remove the default allocator and make the advanced allocator used by default, and that modes don't have to explicitly set it.

• This PR contains a decent amount of code. I have tested it myself by making 8 clients connect to a test server on my computer and trying out various situations. While it seems to work well, there is enough of a possibility of weird bugs that it would be good for additional testing to be done before the PR is merged.

• This PR has been tested locally