[PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY)

Hi

This patch adds an ability to use patterns in *LISTEN* commands. Patch uses
'*SIMILAR TO*' patterns for matching *NOTIFY* channel names (
https://www.postgresql.org/docs/9.0/static/functions-matching.html#FUNCTIONS-SIMILARTO-REGEXP
).

This patch is related to old discussion in
https://www.postgresql.org/message-id/52693FC5.7070507@gmail.com. This
discussion contains the reasoning behind the pattern based matching of the
channel names.

Patch allows the following.
The listener is registered with following command, for example:
*LISTEN SIMILAR TO 'test%';*
which would match and receive a message from this example notfication:
*NOTIFY test_2;*
Unlistening the above registered pattern:
*UNLISTEN 'test%';*
More examples can be seen from the added regress and isolation tests.
Note that *UNLISTEN* does not allow pattern based unlistening of the
registered listeners. It merely matches the registered pattern by simple
string comparison.

This patch has no know backward compatibility issues with the existing
*LISTEN*/*UNLISTEN* features. This is because patch extends the existing
syntax by accepting quoted strings which define the patterns as opposed to
the existing SQL literals.

The patch also extends the isolationtester by adding an ability to monitor
registered notify messages. This is used to test the existing features as
well as the new pattern based feature. (Does not affect other existing
tests)

Further considerations for this patch:
- Change pattern type, alternatives would be e.g. *LIKE* or POSIX patterns
- Remove '*SIMILAR TO*' from the command (just use quoted string in
form of *LISTEN
'test_%'*)
- Allow *UNLISTEN SIMILAR TO 'xxx'* which would unregister matching
listeners. To me this feels confusing therefore it is not in the patch.

Some notes about patch:
- Most of the changes in async.c
- Regular expression is compiled and finally stored in top memory context
- RE compilation (+error check) happens before transaction commit
- RE is compiled in current transaction memory context from where it is
copied to top memory context on transaction commit (when everything first
succeeds)
- Compiled REs in current transaction are freed on transaction abort
- Compiled REs that were not applied as listeners (duplicates) are freed on
transaction commit
- REs freed when unlistened
- No obvious performance impacts (e.g. normal channel name listening uses
just strcmp)

Thoughts?

Best regards
Markus