Primitive SUBSCRIBE request
WIP: Provide UAS processing for NOTIFY requests

At the moment, the UAS does not seem to recognise that this is part of
a dialog.  I'm probably missing something obvious.
WIP: Add an experimental watcher for testing notification handling
Establish a dialog upon a 200-class response to a SUBSCRIBE request

In our case, we are not ever going to send a SUBSCRIBE on a
pre-existing dialog, so this covers the standard case for establishing
a new dialog.

What is currently _not_ handled by this is the establishment of a new
dialog if the matching NOTIFY request arrives before the response to
SUBSCRIBE.

See section 3.3.4 of RFC 3265.
Treat a 200-class response to SUBSCRIBE as a confirmation of the dialog

The initiation of a dialog for a subscription doesn't require any
further requests for confirmation.
Fix parsing of SIP URIs that are not enclosed within angle brackets

These following the rules in Section 20 of RFC3261 where parameters
are treated as header parameters rather than URI parameters when not
enclosed by angle brackets.

The primary symptom was that the 'tag' parameter was ending up in
#uri.opts rather than #uri.ext_opts.