Add initial request timeout which is different from game timeout

[Debilski]

When playing against a network bot, it makes sense to specify a different initial timeout.

The network bot might need some time to start up; or the network server might have some throttling mechanism implemented to only allow for a number of connections at the same time. We currently take the value from --set-timeout or have a non-configurable default (usually 3).

[Debilski]

Outline/TODO

Split class RemoteTeam in two to make the distinction a bit clearer:

One class that starts its own subprocess and owns it (the ‘classic’ remote team).
One class for handling connections to a server-run remote Pelita client.

The game methods should be agnostic whether they have a Team or one of the remote team classes.

In the first case, we start the subprocess and keep track of it in our class. The subprocess is responsible for sending an OK message once it has started. (zmq.PAIR)

In the second case, we request a match with a zmq.DEALER socket sending a message to a Pelita server. Again, the server (which should relay this to its player subprocess) will send an OK message, when the subprocess has started.

The OK messages will be awaited asynchronously in setup_teams (and not in RemoteTeam.__init__ as is the case now), perhaps via a *Team.is_ready method.
Once both players are ready, the set_initial message is sent out. If one of the players is not ready after the setup timeout, the match is aborted.

Further modification/simplification: The player’s OK message the player should also include its team name so it can already be included in the set_initial message for both teams. (And be left out in all subsequent messages.)

(We kind of could also skip the whole set_initial message then – and include everything in the first get_move but I’m not sure.)