fix: graceful error on non-UTF-8 --time-style value instead of panic

[SAY-5]

Description

eza --time-style VALUE aborted with a panic (exit 134) when VALUE was not valid UTF-8, e.g. eza --time-style "$(printf '\xff\xfe')" .. The custom TimeFormatParser::parse_ref called value.to_str().unwrap(), and OsStr::to_str() returns None for non-UTF-8, so the .unwrap() panicked.

This makes the parser return a clap InvalidUtf8 usage error when the value is not valid UTF-8, matching how every other flag rejects bad input. The sibling env-var path in view.rs already handles this with to_str().unwrap_or("").

Fixes #1837.

How Has This Been Tested?

Original validation recorded when this PR was opened:

cargo test --lib passes, including a new #[cfg(unix)] regression test that feeds a non-UTF-8 --time-style value and asserts a usage error rather than a panic. Manually confirmed eza --time-style "$(printf '\xff\xfe')" . now prints error: invalid UTF-8 in --time-style value instead of crashing. cargo fmt and cargo clippy --lib are clean.

October 2 CI follow-up: the two --version/-v power-test snapshots still expected 0.23.4 although this branch's Cargo.toml declares 0.23.5. Updated only those version lines. Both original snapshots failed locally with that exact mismatch; both pass after the correction.

Validation for this follow-up on macOS ARM64 with Rust 1.90.0, default Git support, and the locked dependencies:

• cargo test --locked --offline --features powertest --test cli_tests cli_powertest_tests -- --exact trycmd=ptest_af29d370729835d8.toml trycmd=ptest_a82ad7ec2e961f84.toml: both cases passed.
• cargo test --locked --offline --features powertest --lib: 356 passed, including the non-UTF-8 regression.

Dependencies were vendored from the exact locked archives; debug symbols and incremental compilation were disabled. The Linux Nix integration suite was not run locally and still needs hosted CI. Codex assisted with diagnosing this CI failure, the two snapshot edits, and this follow-up validation and description.