Prevent AudioCommands being freed before read

When AudioCommandThread::threadLoop process AudioCommands it was
possible for it to delete a command where the posting thread still
hadn't read that status from it.

If a second command signaled the thread loop to continue after it
had inserted a new command while the thread loop was actually waiting
for the first command to report that it had read the status the
thread loop would continue and delete the first command.

Changed the wait condition when waiting for the calling thread to
read status to use command->mCond instead of mWaitWorkCV. This way
it's guaranteed that the signal to continue comes from the correct
thread.

Change-Id: Ia69b48cb4fdfaf8b4c83b56a197fb9f2058a92d1
Merge "Prevent AudioCommands being freed before read" into jb-mr1

Change-Id: I8001ce451f6689ca3fa811cde82151702fe57a58