Implement methods that are needed for Mario Kart 7 communities to work.
Note that support for communities on MK7 is partial since the community
statistics don't load because legacy Ranking isn't implemented. Aside
from that, players can create communities and join others without
issues. Other games which use persistent gatherings may or may not work.
In order to support the `ParticipationCount`, we replace matchmake
session joins with a wrapper which checks if the session is attached to
a community, and if it is, it will increment the participation count of
the player in a new table named `community_participations`. The
`MatchmakeSessionCount` is handled more easily by checking the sessions
that belong to the corresponding community.
A new parameter is also added named `PersistentGatheringCreationMax`
with a default value of 4, as reported and tested on various games. This
allows game servers to change the maximum number of active persistent
gatherings that a player can create. For example, Mario Kart 7 supports
up to 8 persistent gatherings instead of the default of 4.
In Mario Kart 7 there is no limitation on the number of players that can
"join" to a community. That is because they don't really join to it but
they create matchmake sessions linked to the persistent gathering (in
fact, the `MaximumParticipants` parameter on persistent gatherings is
set to 0). Thus, the `participants` parameter is unused in communities
(at least on MK7) and we instead log community participations with a new
tracking table `tracking.participate_community`.
Some changes also had to be done in other places like participant
disconnection handling or gathering registrations in order to implement
persistent gatherings accurately.
Assign a new host when the current host is disconnecting from a
gathering. To simplify the implementation, set the owner of the
gathering as the new host.
Fixes Splatoon where the client doesn't transfer the host by
themselves.
Keep tracking on gathering (un)registrations, participants joining and
leaving and host and owner changes. All tracking is managed inside the
database functions except for the host and owner changes.
The `matchmaking.participants` now remains useless from this change at
the moment, so remove it for now.
The concept of negative PIDs was a guess and wouldn't make sense on the
Switch. Instead, replace it with storing the "main" PID multiple times
on the participants array.
