Primitive SUBSCRIBE request
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.
Provide callback for handling NOTIFY requests from an nksip_sipapp

Right now this callback is incredibly naive and assumes that the
sipapp itself will take care of the implementation for the event
packages it is interested in.

Once we get a better picture of what can be generalised, we can start
to handle the book-keeping directly in nksip.
WIP: Add an experimental watcher for testing notification handling

Right now this module fails to do any book keeping to manage the
subscription.