merge our local changes to bufio though.

ibuf is just too confusing since there is also the 'struct ibuf'.

This makes using amused a bit nicer on termux where /tmp/ can't be written (or doesn't even exists.) amused still uses /tmp/ if TMPDIR is not specified.

libevent is a very cool library, I like its APIs and enjoy using it. However, for amused it is maybe a bit too much since it doesn't deal with too many file descriptors. Amused only needs to monitor one fd for the player process and the currently connected clients. Given that it runs per-user locally, having more than a dozen of fds open is very, very rare.

used @openbsd.org initially by mistake and got copied around in most files. Since this has nothing to do officially with the OpenBSD project, use my own email address.

First move towards a change in the behaviour of `monitor': advancement on tracks during the play are reported also every second, as the music is played, not only when there's an explicit seek.

the consume mode implicitly drops the tracks from the playlist when played 'till the end (note that skipping over a track doesn't trigger the consume mode - yet?)

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.

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.)

see GitHub issue #1