Clarify netflow padding algorithm descriptions

I just had an IRC chat with Mike about padding-spec section 2 in preparation for our work on arti#62 (closed). I'll make some patches to clarify all the issues we covered.

Issues I should resolve include:

• It appears that we believe netflow logging is directional, so we actually only reset our timers when we write. Not when we read.
• We reset when we write any cell, including padding.
• nf_conntimeout_clients applies to circuit prediction timing logic, and probably needs more detail.
• We currently do padding negotiation after NETINFO, and not at any other time.
  • Clients never have to receive negotiation.
  • Clients respond to negotiation messages by ... dropping? Closing channel? See channelpadding_update_padding_for_channel()
• We do max(X,X) distribution even though we're being unidirectional.
• The rationale for randomizing at all is that we want to make it not-completely-trivial to tell if a message is padding.
• We behave as if the timer reset after every cell sent.
• If possible, it's better to time based on when our last cell was flushed, not when it was queued. That might not be so easy.