chan_pjsip: Fix crash on reINVITE before initial INVITE completes.

Apparently some endpoints attempt to send a reINVITE before completing the
initial INVITE transaction.  In this case PJSIP responds appropriately to
the reINVITE with a 491 INVITE request pending.  Unfortunately chan_pjsip
is using the initial INVITE transaction state to determine if an INVITE is
the initial INVITE or a reINVITE.  Since the initial INVITE transaction
has not been confirmed yet chan_pjsip thinks the reINVITE is an initial
INVITE and starts another PBX thread on the channel.  The extra PBX thread
ensures that hilarity ensues.

* Fix checks for a reINVITE on incoming requests to look for the presence
of a to-tag instead of the initial INVITE transaction state.

* Made caller_id_incoming_request() determine what to do if there is a
channel on the session or not.  After a channel is created it is too late
to just store the new party id on the session because the session's party
id has already been copied to the channel's caller id.

ASTERISK-25404 #close
Reported by: Chet Stevens

Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be