Explicit quit and ping timeout behave the same way,
but reattach after abandoning/losing the previous session
(without the break being detected server-side) is more aggressive
about replaying missed messages, at the cost of potential duplication.

https://bugs.torproject.org/29665 describes how single-onion circuits
will close unless the client sends data every 60 seconds. To cause the
client to send these messages, have Oragono send the client a PING every
30 seconds.

Sequence of events:

1. client.nickTimer.Stop()
2. client.server.accounts.Logout(client)
3. accounts sees that client is no longer logged in, does client.nickTimer.Touch()
4. 30 seconds later, RandomlyRename resurrects the zombie client

* Clients are now renamed, not disconnected, on reservation timeout
* Nick reservation config is now its own subsection

squigz on freenode reported an issue where bots were responding to PING
on time, but were occasionally being timed out regardless. This was a race
condition: timeout was detected as idleTime >= it.quitTimeout, but if
the client responded promptly to its PING message and sent no further messages,
but the main loop subsequently slept for longer than expected (i.e., significantly
longer than quitTimeout), this condition would be met through no fault of the
client's.

The fix here is to explicitly track the last time the ping was sent, then test
!lastSeen.After(lastPinged) instead (making use of time.Time's monotonicity).
It is sufficient that the measurement of lastPinged happens-before the PING is sent.

* move constant definitions
* always give the client at least quitTimeout to respond to ping,
  even if registerTimeout or quitTimeout are longer than idleTimeout