Use libav/ffmpeg for audio decoding

libav 9.12 and ffmpeg 2.2 have been tested.

Here’s why: My mp4 “parser” *cough* never was a mp4 parser in the sense
that it actually understood the file format. Instead it grepped the
input stream for “magic” strings (section identifiers). That alone
should be sufficient to throw away the code and rewrite it. Additionally
libfaad2 has not been updated for ages. I guess it was abandoned in
favor of libav/ffmpeg.

With libav/ffmpeg, which we support both as long as the API’s don’t
diverge too much, pianobar gains fast and reliable AAC and MP3 decoding
without bothering too much about the details. Most users will have it
installed already. On my own machine libav consumes about 2/3 CPU time
compared to the previous solution when playing AAC. Unfortunately memory
usage doubled and my attempts to disable unused protocols/formats/codec
failed due to libav’s API limitations.

While cleaning up a small detail regarding the eventcmd API has changed
too: Song duration and position are measured in seconds instead of
milliseconds now. Since libav/ffmpeg keeps track of accurate timing the
precision pianobar keeps track of can be reduced, while still being
sufficient for most users.
Fix compiler warning
Send the server_name extension.

Required by sniproxy when forwarding the connection.
Send headers in first packet.

Splitting up the writes causes the Host header to end up in a
different packet than the requst line, making it harder to proxy.
player: discard unused streamns

Shouldn’t make a difference right now. Just in case…
ffmpeg compatibility

Adds support for ffmpeg 2.2 and 1.2. Right now the maintenance overhead
of supporting both libav implementations is not that big.

Fixes #437 and #435.
Merge branch 'master' of https://github.com/PromyLOPh/pianobar