Fixes sip extension state update DEADLOCK

Fixes sip extension state update DEADLOCK

PROBLEM:
In chan_sip, and all the other channel drivers, it is common for
us to hold the tech_pvt lock while we ask the Asterisk core about
an extension and context.  Every time we do this the locking
order becomes, (1. tech_pvt lock ---> 2. global context lock). In
chan_sip when a dialog subscribes to a hint, that locking order
is reversed in the extensionstate callback which will occur outside
of the channel_driver's monitor loop.  So, on an extension state
update we have (1. global context lock ----> 2. tech_pvt lock).

Typically when we have to do a reversed locking order like this
we'd just do some sort of deadlock avoidance to fix the problem...
That will not work here.  There are more locks involved here than
just the context and tech_pvt.  Those are the two that are colliding,
but it is impossible to give up the context lock because the global
hints list lock MUST be held as well and we can not give that lock
up during the extensionstate callback traversal... The locking order
for the context and hints are (1. global context lock ----> 2.
hints list lock).  Deadlock avoidance is not an option here.

SOLUTION:
The solution this patch implements is to queue the extension state updates
into a list and send the NOTIFY messages out during the do_monitor pvt
traversal.  This clears out the problem of having to hold the context
lock before the tech_pvt lock entirely.

(closes issue #17888)
Reported by: zerohalo

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@286070 65c4cc65-6c06-0410-ace0-fbb531ad65f3