feat(protocol): folder requests, and heuristics matched to other clients

Reading Nicotine+ and slskd against what was just written turned up three
places where this client had the message right and the behaviour wrong.

Excluded search phrases (code 160) are not a filter on the searches we
send — the server already drops those. Nicotine+ applies them to the files
it offers, leaving out any whose path carries an excluded phrase, and a
reply with nothing left is not sent. Ours now does the same, and the
local refusal of outgoing searches is gone.

Serving children now follows the same rules as Nicotine+: the limit comes
from the server's ParentMinSpeed and ParentSpeedRatio against the upload
speed the server records for us (capped at ten, none at all below the
minimum), children are refused until something feeds us the search stream
and let go when it stops, a second link from a child we already carry is
refused, and AcceptChildren is re-sent whenever that answer changes. Where
the server has never reported our speed there is nothing to apply the
formula to, so the configured cap stands, which is how slskd runs.

Queued downloads now ask where they sit every five minutes, as Nicotine+
does, instead of only when a caller asks; a brokered file connection we
cannot complete reports CantConnectToPeer like a control connection does;
and a peer's shares can be asked for one folder at a time (peer code 36
and its reply, 37), which is what "download folder" is built on.

soulseek-rs-lib/src/message/peer/folder_contents.rs

@@ -26,6 +26,37 @@ impl MessageHandler<PeerMessage> for FolderContentsRequest {
     }
 }
 
+/// `FolderContentsResponse` (peer code 37): the reply to a folder we asked
+/// for. The token is the one we quoted, so a client with two folders in
+/// flight can tell the answers apart.
+pub struct FolderContentsResponseHandler;
+impl MessageHandler<PeerMessage> for FolderContentsResponseHandler {
+    fn get_code(&self) -> u32 {
+        37
+    }
+    fn handle(&self, message: &mut Message, sender: Sender<PeerMessage>) {
+        let Some((token, folder, directories)) = parse_folder_contents(message)
+        else {
+            return;
+        };
+        let _ = sender.send(PeerMessage::FolderContentsReceived {
+            token,
+            folder,
+            directories,
+        });
+    }
+}
+
+/// Build a `FolderContentsRequest` (peer code 36).
+#[must_use]
+pub fn build_folder_contents_request(token: u32, folder: &str) -> Message {
+    Message::new()
+        .write_int32(36)
+        .write_int32(token)
+        .write_string(folder)
+        .clone()
+}
+
 /// Build a `FolderContentsResponse` (peer code 37).
 #[must_use]
 pub fn build_folder_contents(