chan_pjsip: Fix attended transfer connected line name update.

A calls B
B answers
B SIP attended transfers to C
C answers, B and C can see each other's connected line information
B completes the transfer
A has number but no name connected line information about C
  while C has the full information about A

I examined the incoming and outgoing party id information handling of
chan_pjsip and found several issues:

* Fixed ast_sip_session_create_outgoing() not setting up the configured
endpoint id as the new channel's caller id.  This is why party A got
default connected line information.

* Made update_initial_connected_line() use the channel's CALLERID(id)
information.  The core, app_dial, or predial routine may have filled in or
changed the endpoint caller id information.

* Fixed chan_pjsip_new() not setting the full party id information
available on the caller id and ANI party id.  This includes the configured
callerid_tag string and other party id fields.

* Fixed accessing channel party id information without the channel lock
held.

* Fixed using the effective connected line id without doing a deep copy
outside of holding the channel lock.  Shallow copy string pointers can
become stale if the channel lock is not held.

* Made queue_connected_line_update() also update the channel's
CALLERID(id) information.  Moving the channel to another bridge would need
the information there for the new bridge peer.

* Fixed off nominal memory leak in update_incoming_connected_line().

* Added pjsip.conf callerid_tag string to party id information from
enabled trust_inbound endpoint in caller_id_incoming_request().

AFS-98 #close
Reported by: Mark Michelson

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

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

Merged revisions 421403 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@421404 f38db490-d61c-443f-a65b-d21fe96a405b
ARI: Fix a bug where /channels/{channelID}/continue doesn't execute PBX

If /channels/{channelID}/continue is called on a channel that was originated
without a PBX (such as the ARI command POST channel with a stasis application
argument), the channel will not start dialplan execution. This patch will now
run the PBX out of the stasis execution if the channel doesn't currently have
an active PBX upon continuing.

ASTERISK-24043 #close
Reported by: Krandon Bruse
Review: https://reviewboard.asterisk.org/r/3917/
Patches:
    stasis-continue.diff submitted by Krandon Bruse (license 6631)
........

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

Merged revisions 421423 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@421424 f38db490-d61c-443f-a65b-d21fe96a405b