Fix a deadlock in device state change processing.

Fix a deadlock in device state change processing.

Copied from some notes from the original author (Russell):

Deadlock scenario:
Thread 1: device state change thread
  Holds - rdlock on contexts
  Holds - hints lock
  Waiting on channels container lock

Thread 2: SIP monitor thread
  Holds the "iflock"
  Holds a sip_pvt lock
  Holds channel container lock
  Waiting for a channel lock

Thread 3: A channel thread (chan_local in this case)
  Holds 2 channel locks acquired within app_dial
  Holds a 3rd channel lock it got inside of chan_local
  Holds a local_pvt lock
  Waiting on a rdlock of the contexts lock

A bunch of other threads waiting on a wrlock of the contexts lock

To address this deadlock, some locking order rules must be put in place and
enforced. Existing relevant rules:

1) channel lock before a pvt lock
2) contexts lock before hints lock
3) channels container before a channel

What's missing is some enforcement of the order when you involve more than any
two. To fix this problem, I put in some code that ensures that (at least in the
code paths involved in this bug) the locks in (3) come before the locks in (2).
To change the operation of thread 1 to comply, I converted the storage of hints
to an astobj2 container. This allows processing of hints without holding the
hints container lock. So, in the code path that led to thread 1's state, it no
longer holds either the contexts or hints lock while it attempts to lock the
channels container.

(closes issue #18165)
Reported by: antonio

ABE-2583

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