Timeout-guard subprocess calls to awww, wal, and bread-theme

wallpaper.rs/pywal.rs/theme.rs each shelled out via a bare
Command::new(...).status() with no timeout — a wedged awww-daemon, pywal
choking on a corrupt/huge image, or a hung bread-theme reload could each
block breadpaper indefinitely. Switched to bread_utils::proc::run (path
dependency for now, see the TODO in Cargo.toml), matching the exact
"anything shelling out to awww" case named in tonight's ecosystem-utils
audit.

src/wallpaper.rs

@@ -1,17 +1,15 @@
 use std::path::Path;
-use std::process::Command;
+use std::time::Duration;
 
-use anyhow::{Context, Result, bail};
+use anyhow::{Result, bail};
 
 pub fn apply(path: &Path) -> Result<()> {
-    let status = Command::new("awww")
-        .arg("img")
-        .arg(path)
-        .status()
-        .context("failed to run awww — is awww-daemon running?")?;
-
-    if !status.success() {
-        bail!("awww img exited with {}", status);
+    // Was a bare Command::new("awww").status() with no timeout — a wedged
+    // awww-daemon (compositor not ready yet, IPC socket stuck) used to be
+    // able to hang this call indefinitely.
+    let out = bread_utils::proc::run("awww", &["img", &path.to_string_lossy()], Duration::from_secs(10));
+    if !out.success {
+        bail!("awww img failed (is awww-daemon running?): {}", out.stderr.trim());
     }
     Ok(())
 }