rethink a bit which event are reported and when. - drop 'toggle' event as it's not useful; now 'amused toggle' will report the play/pause event. - replace 'flush' with 'load'. there's no real difference between a flush and an empty load. (also, less event the better) - some events (next/prev/jump) are reported earlier to avoid possible issues (when messing around with the playing queue we can end up in every possible state.) - report 'seek' only after it really happened (i.e. after the player process sent the new position.) There's still a possible race here (we can receive a previous IMSG_POS and think it's the reply to the seek) but it it's hard/impossible to work around. - drop 'restart'. we have 'seek' now which is better (and actually restart is implemented on top of seek.) - add 'seek' to the default list of events.

`amused monitor' defaults to report all the events, that should be enough.

it's awkward to call it with the address of the imsgev struct inside the ctl_conn struct. Just relay the info to every client in monitor mode. After all, if a client is in monitor mode *and* issues commands, it's not strange that they're echoed back (note that this is currently impossible, the command line client can either issue commands or be in monitor mode.)

instead of passing "half" of the context wanted, just take the number of lines wanted. switch to a circular buffer to store the lines instead of shelling out (badly) to grep -C.

otherwise we may leave it NULL (it's set only in ctl_status) and crash in print_status.

better to use a control variable rather than `last' from a subroutine

This add a -f flag (that falls back to $AMUSED_STATUS_FORMAT) to control which field to print and in which order.