bridge_native_rtp/bridge_channel: Fix direct media issues due to frame hook

This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.

The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
    enter a bridge together, the framehook remains on the transfer target
    channel until both channels are in the bridge. As it consumes voice frames,
    the initial bridge type is a simple bridge. The framehook is removed when
    both channels are in the bridge; however, this does not currently cause the
    bridging framework to re-evaluate the bridge. This patch adds a
    AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
    framehook is removed so the bridge can re-evaluate itself.

(2) When a channel leaves a native RTP bridge, it may be leaving due to being
    hung up. Sending a re-INVITE to a channel that is about to be hung up is
    not nice - in fact, there's a good chance we'll send the BYE request before
    the channel has had a chance to send back a 200 OK. To be somewhat nicer,
    this patch adds a function to channel.h that allows the bridging framework
    to query for exactly why a channel is leaving a bridge via the channel's
    soft hangup flags. This allows it to only send the re-INVITE if there's a
    chance the channel will survive the native bridging experience.

Review: https://reviewboard.asterisk.org/r/3535/
........

Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12


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