Issues with `Player.__hash__` and `Player.__eq__` implementation

[Askaholic]

Right now Player objects are considered equal if their ID's are equal. However, this can cause issues when players reconnect where a new Player object is created and there are still some old ones hanging around.

For example:

1. Player starts a matchmaker game
2. The game ends and the player leaves the game and immediately reconnects
3. The player tries to queue for matchmaker

What happens is in step 3, sometimes the on_connection_lost logic has not triggered yet for the services, so the old Party object is re-used for the new player due to the hash/eq implementations. However, the party object still references the old player which has a player state of PLAYING, so the new player is falsely prevented from queuing.

Really we should rework the hash implementation so that different objects have different hashes. My initial thought was something like hash(id(self)) or hash((self.id, id(self))), but this seems to cause some of the unit tests to fail due to a changed ordering of entries in certain dictionaries, so it will require a bit of work to figure out why that changes happens and how to make it work properly.