Deadlocks in player.c

[mahkoh]

We have a serious problem with deadlocks in player.c. When the player asks the UI thread for the next track, it will block until the UI thread responds and continues to hold one of the player locks while it waits. If the UI thread at the same time tries to acquire one of the player locks for some reason (e.g. to change the track manually) we have a deadlock.

I've discovered this while debugging another problem that caused cmus_get_next to be called in rapid succession. Luckily this doesn't seem to happen that often normally.

Right now I see two ways to fix this:

• Make cmus_get_next async: This is hard because the player code is very complicated and uses a completely synchronous design.
• Release the locks while waiting in cmus_get_next: This is easier but still quite complicated. It is unclear which invariants could be violated if we temporarily release the lock.

[flyingmutant]

Reopening because of #754