player: handle seek delays differently

The code removed from handle_input_and_seek_coalesce() did two things:

1. If there's a queued seek, stop accepting non-seek commands, and delay
   them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
   trying to decode and display the first video frame), stop accepting
   seek commands (and in fact all commands that were queued after the
   first seek command). This logic is disabled if seeking started longer
   than 300ms ago. (To avoid starvation.)

I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.

The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.

One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).

Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.