Fix crash due to incorrect condition variable usage

[peter-esik]

• There was a race condition on the condition variable, when ChangeList::Flush called notify_all. After the waiter (in this case, the main thread) is woken up, notify_all might not have returned just yet. If the main thread proceeded and called Clear on the ChangeList object in the meantime, the condition variable is deleted when notify_all is still executing, causing a crash. This occurs frequently on my machine when running the tool in "branching mode", and there are changelists happening on lots of "uninteresting" branches (in other words: changelists with 0 files to be committed).
• As part of the bugfix, synchronization in the ChangeList class is reworked: instead of multiple atomic variables, mutexes, and condition variables, a single condition variable and mutex is used, with a state machine.

[peter-esik]

Some additional thoughts:

• Depending on the condition variable implementation (in general), a signal/broadcast operation might be performed without holding the lock associated with the CV. However, most use cases are never exposed to this "edge case", because they signal/broadcast after modifying the shared state, and they acquire the lock before doing so.
• Even if the implementation allows this, deleting the CV after a wakeup can lead to a crash in this case, as code in a signal/broadcast operation might run after waiters are woken, accessing internal state of the condition variable (e.g. see the glibc source).
• According to my measurements (with Instruments), synchronization overhead is barely measurable in this tool, so this change from atomic variables has no performance implications, at all.

[twarit-waikar]

This is an interesting case that you have found, thanks for sending in this PR. I agree the possibility of a crash is here and this is one easy way to fix it.