fix(cpu): don't panic when SMT cannot be enabled

[6jrx]

Cpu::new() unwraps the result of opening /sys/devices/system/cpu/smt/control for writing:

https://github.com/ShadowBlip/PowerStation/blob/v0.8.1/src/performance/cpu/cpu_features.rs#L29-L31

That knob only exists when the kernel is built with CONFIG_HOTPLUG_SMT, and /sys isn't always writable. When either is the case the daemon aborts, and since Cpu::new() is the first thing main() does, nothing else gets a chance to run — no GPU discovery, no DBus interfaces, no log line explaining why.

Reproducing it is as easy as starting PowerStation somewhere /sys is read-only:

INFO  [powerstation] Starting PowerStation v0.8.1

thread 'main' (41529) panicked at src/performance/cpu/cpu_features.rs:31:22:
called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }

After:

INFO  [powerstation] Starting PowerStation v0.8.1
WARN  [powerstation::performance::cpu::cpu_features] Unable to enable SMT: Permission denied (os error 13)
INFO  [powerstation::performance::cpu::cpu_features] Core Map: {12: [CPUCore { number: 8, ...

Both set_smt_enabled() and set_boost_enabled() already turn the same kind of failure into a DBus error rather than panicking, so this only brings startup in line with the rest of the file. Behaviour on a system where the write does succeed is unchanged.

Found while testing #37; unrelated to it, so it's on its own branch off main.