Fixed: the client's weapon desynced if they fired it too early after respawning

This addresses ticket #1116, and to some extent ticker #3980, on the tracker.

In the time between when the client respawns on the server's end and when they respawn on the client's end, the client is continuously sending CLC_CLIENTMOVE commands and might still be pressing BT_ATTACK. If so, then if you look at the code in ClientMoveCommand::process, the server will try selecting the weapon the client had selected before they respawned (i.e. what they sent in moveCmd.usWeaponNetworkIndex) if they still have it after respawning. This is because the client's ReadyWeapon is still nullptr until the server receives and processes a CLC_WEAPONSELECT command from them.

To fix the desync, I had to add a new member in CLIENT_s to keep track of which gametic the player respawned on the server's end. The server will not try to select the weapon the client "thinks" it's using if the CLC_CLIENTMOVE command sent by them has a server gametic that's less than or equal to the respawn gametic. Strictly speaking, the server should now process a CLC_WEAPONSELECT command from the client before processing any CLC_CLIENTMOVE commands that were sent after they respawned.

I cleaned up ClientMoveCommand::process first to make it easier to integrate the fix I made, and it's much easier to read the code now.