Deadlock between PJSUA LOCK and conference mutex (thanks Marcus Froeschl for the report)

[nanang]

Deadlock scenario:

Thread 1 (audio playback thread):

1. play_cb() calls conference get_frame()
2. conference mutex is acquired, and conf starts collecting frames from ports
3. wav player (a conf port member) triggers EOF callback to application
4. application calls pjsua_conf_disconnect()
5. check_snd_dev_idle() in pjsua_conf_disconnect() tries to acquire PJSUA LOCK that is being held by thread 2.

Thread 2 (pjsua worker thread):

1. pjsua_call_on_state_changed() invoked
2. PJSUA LOCK is acquired
3. pjsua triggers on_call_state() callback to application
4. application calls pjsua_conf_connect()
5. pjsua_conf_connect() waits for conference mutex that is being held by thread 1.

[nanang]

(In [3977]) Fix #1464: Only use PJSUA lock in PJSUA implementations of INVITE session callbacks when updating 'pjsua_var' is needed, while updating 'pjsua_call' should be enough with call/dialog lock (which is actually being held by the INVITE session layer during invoking its callback).