Fixes for iTunes v10.5 time-outs.

Details:

iTunes v10.5 clients changed how they responded to DAAP
protocol, and started disconnecting when the forked-daapd server
sent an empty "refresh" reply ("mupd" protocol).  This problem is
also coupled with session-timeout ("mstm" and "msal"); when these
server capabilities were enabled, iTunes 10.x clients did not poll
for updates and eventually disconnected.

I investigated DAAP network packets using Wireshark.  I found that
a true iTunes server sends a set of server capabilities in a specific
order, and order matters to the client.  When the correct order is used,
the client correctly polls for updates and does not disconnect.

This change:
  1. Send server capabilities in different order (daap_reply_server_info).
  2. Disables 5-minute update refresh.
  3. Disables 30-minute inactivity time-out.

Testing:
This server version successfully stayed connected to the
following clients:
  * iTunes 10.5.2
  * iTunes 10.4.2
  * iTunes 9.7.1
  * Rhythmbox 0.12.8
The clients stayed connected for at least several hours,
sometimes days, with activity or no activity.
Fixes for Amarok and Banshee clients which don't send
revision-number in their update request.

Details: Banshee (v1.6.1) and Amarok client players send an
update request but do not send the revision-number parameter.
iTunes version 10 (and perhaps earlier) does send this parameter.
See: https://github.com/jasonmc/forked-daapd/issues/78

Fix: function daap_reply_update() now warns when revision-number
is not submitted by the client, but does not reply with an error.
In that case the server assumes a revision-number which insures
an update is sent back to the client.

Testing:
I verified that the following clients were able to connect succesfully
and retrieve a library listing:
  * iTunes 10.5.2
  * iTunes 10.4.2
  * iTunes 9.7.1
  * Rhythmbox 0.12.8
  * Banshee 1.6.1
I can't test with Amarok since I don't have this client.