Clarify listenonion

> This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.

But it is correct to say that the feature is enabled *regardless* of whether a connection to Tor can be made.

I propose to clarify that so that users can eliminate these in their logs (when `listen=1` and no Tor).
And I think it's okay to clarify about the `listen` option, because on several occasions when I read this before I always assumed `listening` meant `server=1` which cost me a lot of time in troubleshooting.

```
2016-10-24 06:19:22.551029 tor: Error connecting to Tor control socket
2016-10-24 06:19:22.551700 tor: Not connected to Tor control port 127.0.0.1:9051, trying to reconnect
```

### What version of bitcoin-core are you using?
0.12.1

doc/tor.md

@@ -99,10 +99,10 @@ This means that if Tor is running (and proper authentication has been configured
 Bitcoin Core automatically creates a hidden service to listen on. This will positively 
 affect the number of available .onion nodes.
 
-This new feature is enabled by default if Bitcoin Core is listening, and
-a connection to Tor can be made. It can be configured with the `-listenonion`,
-`-torcontrol` and `-torpassword` settings. To show verbose debugging
-information, pass `-debug=tor`.
+This new feature is enabled by default if Bitcoin Core is listening (`-listen`), and
+requires a Tor connection to work. It can be explicitly disabled with `-listenonion=0`
+and, if not disabled, configured using the `-torcontrol` and `-torpassword` settings.
+To show verbose debugging information, pass `-debug=tor`.
 
 Connecting to Tor's control socket API requires one of two authentication methods to be 
 configured. For cookie authentication the user running bitcoind must have write access