Tone generator: fixes for low latency audio

TL;DR; fixes a race condition in audio when making a call

Squashed commit of the following:

commit e47286acdb49cda23ec07849c6932d31c469e610
Author: Eric Laurent <elaurent@google.com>
Date:   Mon May 13 12:47:53 2013 -0700

    Fix unreleased mutex in ToneGenerator stopTone()

    Commit 09108ade introduced a regression by not releasing
    the ToneGenerator mutex before exiting in case of error.

    Bug: 8852855
    Change-Id: I8ba2755b218842e2034ed8dbd54b18bf2a5fc571

commit 385d87f392c887ea9d17921440abc905d1de276c
Author: Eric Laurent <elaurent@google.com>
Date:   Thu Mar 28 11:58:45 2013 -0700

    ToneGenerator: fix overflow in stopTone

    Fix overflow in tone duration calculation introduced in
    commit 681be039.

    Bug 6607077

    Change-Id: Ie12f13701345c2b2d3be0b3c4d71cbfa2394a29b

commit b6393c76874c2ae0de533826a13125a473fcd2a5
Author: Eric Laurent <elaurent@google.com>
Date:   Wed Mar 27 12:05:40 2013 -0700

    ToneGenerator: fix truncated tones

    The first DTMF tone after a silent period is truncated.
    This is because the phone app starts and stops the tone
    when the user presses and releases the key.
    This combined to the fact that the tones use the low latency path
    and that when the output stream exists standby there is a period
    of several milliseconds during which no audio is mixed until the
    stream is "warmed up".
    The result is that much less audio is generated than the actual
    key press duration.

    The fix consists in storing the tone start time and making sure that
    the number of samples generated corresponds at least to the time difference
    between the tone start and stop commands.

    Bug 6607077

    Change-Id: I070d20dd8600c25a9e5d5a60c1d3313b7917b00d

commit eaadac867b5342b66bd08d5ad72f33c0cc6dac96
Author: Eric Laurent <elaurent@google.com>
Date:   Tue Mar 26 16:37:19 2013 -0700

    ToneGenerator: fix stop/destroy concurrency

    There is a problem if the stopTone() method is called
    from two different threads (for instance if the destructor is called
    while stopTone() is waiting for the audio callback to finish).

    In this case, the second call to stopTone() will not wait for the
    condition to be signaled and call clearWaveGens() while the callback
    can still be active, thus causing a crash.

    There is a similar problem in case of concurrent calls to startTone()
    and stopTone().

    The fix consists in making sure that stopTone() always waits for call
    back completion or timeout and exits before calling clearWaveGens()
    if a concurrent start request is detected.

    Bug 8163071

Change-Id: I9ddb4390407701dcad5bf83660fd9903f0d72268