feat: resume an interrupted download instead of refetching it (#18)

Downloads buffered the whole file in memory and wrote it out only on
success, so an interrupted transfer left nothing behind and always
started over. The START_DOWNLOAD offset was hardcoded to zero on the
download side and discarded on the upload side, so neither half of the
protocol's resume support was wired up.

Bytes now stream into `<file>.part` as they arrive and it is renamed
only once the file is whole. A new attempt sends the partial file's
length as the START_DOWNLOAD offset, and `serve_file` seeks to the
offset a peer asks for rather than replaying from the start. A `.part`
at or past the expected size is treated as stale and restarted.

Partial files are kept out of the share index, since the download
directory is shared by default.

soulseek-rs-lib/src/utils/path.rs

@@ -1,5 +1,11 @@
 use std::path::PathBuf;
 
+/// Extension of the file a download streams into while it is still running.
+///
+/// Downloads usually land in a shared directory, so the transfer code that
+/// creates these and the share scanner that must skip them agree here.
+pub const PART_SUFFIX: &str = ".part";
+
 #[must_use]
 pub fn expand_tilde(path: &str) -> PathBuf {
     if let Some(stripped) = path.strip_prefix('~')