LISTEN/NOTIFY regression tests

This patch adds some primitive regression tests for the LISTEN,
NOTIFY, and UNLISTEN commands -- there were previously no regression
tests for this functionality.

There are currently two problems/caveats with the patch:

      (1) The regression test can never pass, because the message that
          psql produces when a signal is delivered always changes
          slightly between runs of the regression tests, since the
          backend's PID is not constant:

Asynchronous notification "my_cond" received from server process with
PID 15942.

          How should I fix this? What we'd like to be able to say is
          "ensure that the output of the command matches this regular
          expression", rather than the mere equality comparison (with
          allowances for whitespace, etc.) that we are using right
          now.

      (2) At present, we only test notifications that are delivered to
          our own backend. That means we're not testing the code path
          that delivers notifications to other backends (which is
          probably the one more likely to contain bugs). The tests
          I've written are better than nothing, but it would be nice
          to be able to test this functionality more completely.

          The problem with listening for signals in one backend and
          delivering signals in another backend is that we need some
          way to do synchronization between the backends (for example,
          we don't want to execute a NOTIFY on a signal before the
          other backend has had a chance to LISTEN for it). I was
          thinking of implementing this by acquiring exclusive locks
          on a dummy table, but that is kind of a hack, and has its
          own concurrency problems (for example, we need to ensure the
          CREATE TABLE precedes the LISTEN & NOTIFY tests). Any
          thoughts?

          One possibility is just writing a separate little C
          application that does the LISTEN/NOTIFY testing itself, and
          is invoked by the regression test script. The same technique
          would be useful for doing some testing of VACUUM, for
          example. Does anyone else think this would be useful?

#1 needs to be fixed before this patch can be applied, but #2 will
#probably remain an area for future work.

-Neil