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