Prevent spamming hold/unhold requests in SIP

Currently, the SipPhone class assumes that a hold/unhold request is
completed successfully and does not wait for the callback from the
SipAudioCall. Since the SipCall goes into the HOLDING state without
confirmation, an unhold request may be sent before the SipAudioCall
state machine completes its transition into the HOLDING state. If an
unhold is sent to the state machine before the request completes, the
state machine will move into an invalid state and create an error,
disconnecting the call.

Until the SIP telephony code can be refactored, a temporary solution
has been added that waits for a timeout to be reached before another
request can be sent to hold/unhold a call.

Bug: 18383178
Change-Id: I540a14c0709a97dc01ef0d26d8c41712dd8c8525