Add support for LISTEN/NOTIFY

This commit adds support for the PostgreSQL LISTEN/NOTIFY
mechanism by adding two new interfaces:

  - ListenerConn is a low level interface which establishes
    a connection to a PostgreSQL server and only knows how to
    execute simple queries and wait for notifications.  This
    interface does not know how to reconnect, and does not
    maintain a list of the channels it is listening on.  This
    interface is also undocumented, as its use is heavily
    discouraged.
  - Listener is the higher-level interface which uses
    ListenerConn to provide a simpler to use interface,
    supporting automatic reconnection.  In order to do that,
    also knows the list of channels it is already listening
    on.

Significant contributions and ideas from Tommie Gannert.  Ideas
and valuable feedback from Kamil Kisiel and Maciek Sakrejda and
Paul Hammond.
Small changes to docs
Another small change to docs
More doc changes

Sorry Travis.
Reiterate concurrency, disregard databases
Add more comments
Fix two bugs in the simpleQuery/replyChan logic

listenerConnLoop can not send the query buffer over to ExecSimpleQuery
because it's a slice of scratchBuffer which might go away.  Rearrange
things to avoid the need to do that, and simplify the interface while
at it.

Also parseError could panic, so we need to errRecover in
listenerConnLoop.
Small clarification
Add Ping method

This is useful for determining whether the connection is still alive
after some time of inactivity.

I used the empty string as the ping message to abuse the
EmptyQueryResponse special case in postgres.  This way I don't have
to write the logic for receiving and discarding result sets.
Debugging, comments
Replace senderToken with a lock
Minimal changes to docs
More minor changes to docs
Trying to Enlighs
Avoid modifying the scratch buffer in conn.Close()

This could in very rare situations crash the Listener.
Fix mistake in docs
Remove useless comment from the docs

There's no way to access the PID of the Listener's postgres process
so this will likely just confuse people.  Also because the connection
doesn't really execute anything other than LISTEN/UNLISTEN commands,
it would be very unusual for the connection to receive notifications
from itself.
Attempt to clear up channel vs. channel mess in docs
Don't use errClosed

We can't steal it from pq just for Listener's use, that's rude.
Adjust NOTIFY test timeouts