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.
Only include 'Expires' header in a subscribe request if provided

The use of nksip_lib:get_integer/2 means that when undefined, it
defaults to zero.  This removes the possibility of relying on the
default expiration for the package.
Use similar handling of dialogs for subscriptions

This allows us to lean on the existing mechanism for updating the
remote_target; necessary for refreshing subscriptions within a dialog.

Once the new engine changes are released, this can be more completely
implemented.
Provide the ability to reSUBSCRIBE within an existing dialog

The same event and expires options should be provided as this
information is currently not obtained from the dialog.

This avoids us needing to do any deep surgery on dialogs for the
moment until the new engine is in place.  What a SipApp will need to
do is remember the package and provide it with the re-subscribe.
Extend SipApp synchronous call to support calling a core by process and module
Callback to allow a SipApp to provide a list of supported features

This callback is primarily used when checking the contents of the
Require header in a request.  If the list of extensions included in
the Require header is a subset of those supported by the SipApp, then
the request will proceed as usual rather than responding with a bad
extension response.