Consider changing guard reachability definitions for guard-spec.txt

This is low on the priority list, but in #65 (closed) and in guard-spec.txt in general, it bothers me that we define guard readability in terms of connections and circuits. If you comb through the specs closely, they do in fact typically say "circuit or connection" for a lot of cases, but this is easy to misinterpret, and still does not cover everything.

It seems more natural to define a guard as reachable if we have managed to get any sort of encrypted+authenticated network activity from it recently. This can include dirfetch responses, netflow padding cells, TLS handshakes, create_fast.. Literally any encrypted+authenticated packets from a guard should mean that it is reachable.

Defining things in this way instead can help avoid implementation issues where implementations decide to wait around for specific activity such as circuit completion, before defining a guard as reachable, when other activity may happen much sooner. This will avoid churning through guard lists after network loss, which may be a client fingerprinting or Tor user IP address exposure risk while roaming.