Return `404 not found` for some common well-known paths, as clients requesting them usually do that automatically and don't expect endless audio stram.

Closes #572

memcmp use may result in out of bounds access

This missing piece probably never really hurt, because
HttpdClient::OnSocketClosed() would be called right after a socket
error, but it's better to be explicit about closing on error.

Since we switched from autotools to Meson in commit
94592c14, we don't need to include
`config.h` early to properly enable large file support.  Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.

This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.

This code was added in 21851c06 but
looks completely broken:

- the status code is "206 OK" but "206" would be "Partial Content"

- the "Content-Length" header has a bogus value

- the "Content-RangeX" parameter has different bogus values (why
  "Content-RangeX" anyway and not "Content-Range"?)

Apart from that, there are strange undocumented non-standard headers
which are probably there to work around bugs/expectations in one
broken proprietary client product.  But these days, MPD doesn't bend
over to support broken clients.  So let's kill this code.

Closes #304

Passing it by value is actually smaller (32 bit) than the rvalue
reference (64 bit pointer), and it ensures that the object is consumed
after the call returns, no matter how the methods are implemented.

Migrate callers to GetSocket().Read(), GetSocket.Write(), which is the
same.

This eliminates some overhead, because the compiler doesn't need to
consider these functions throwing.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Users now have to call Close() explicitly.  This simplifies using the
class, as most users have automatic socket management already, and
Steal() had to be used often.

Don't let the server care for client problems.

Don't iterate the std::list each time.

Some, or most, Win32 audio players will pass "icy-metadata:1" to
streaming servers. MPD expects a space between ":" and "1" at this
point, and thus does not send any stream metadata. This applies to
foobar2k and Winamp, for example.

According to forums.radiotoolbox.com/viewtopic.php?t=74 not having
a space there is expected behavior, so maybe MPD could accept
both forms to determine if metadata should be sent or not.