[reSIProcate] DUM state & design

["Derek MacDonald" <Derek@xxxxxxxx>]

So, the basic InviteSession API's are fairly cooked and implemented,
although Enqueue/etc could change things.  The AuthManager needs some work,
but 401/407's are being handled in the basic invite/register cases.

I'm going to start hacking PUBLISH/SUBSCRIBE/NOTIFY and the design there
doesn't look particuarily cooked. I've changed the headers to more closely
reflect other API's, but opinions are welcome.

David and I were talking about it, and we think Publish is another type of
usage(def. not a sip dialog, but it has a lifespan) that looks similar to
Registration, w/out the Call-ID being re-used. It seems incorrect that a
Dialog can only have one ServerSubscription but many ClientSubscriptions, so
I'm going to change that barring a compelling reason.

On another topic, I'm adding navigation methods to the AppDialog userdata
that will allow a user to retrieve an invite or sbscription usage.  This
will do for now, but it seems likely that handlers and userdata will be
merged.

--Derek