--thermal: Return data instead of only printing it

[blackdragoon26]

Towards #357.

print_thermal and print_thermal_thresholds did the EC reads, the decoding and the formatting in one function, so nothing but the commandline tool could get at the data.

This splits them in two:

Read the data	Print it
get_thermal(&CrosEc) -> EcResult<ThermalInfo>	print_thermal(&CrosEc)
get_thermal_thresholds(&CrosEc) -> Option<Vec<ThermalThresholds>>	print_thermal_thresholds(&CrosEc) -> Option<()>

The print functions keep their signatures and their output, they just call the getter and format what comes back.

The decoded values get types instead of raw memmap bytes:

• TempSensor is pub now. It was private, so nothing outside power.rs could name a temperature reading even where one was already being returned.
• Fan speeds decode into FanSpeed::{Rpm, Stalled, NotPresent} instead of comparing against 0xFFFE / 0xFFFF at print time.
• Disabled thresholds are None rather than the string "-".
• AP throttle status is Option<ApThrottleInfo> with real bools.

So a consumer can now do:

let thermal = power::get_thermal(&ec)?;
for fan in &thermal.fans {
    if let FanSpeed::Rpm(rpm) = fan.speed {
        println!("{}: {} RPM", fan.name, rpm);
    }
}

One intentional behaviour change

print_thermal used .unwrap() on both memmap reads, so a failed read panicked. It now prints Failed to read thermal information: ... and returns.

Verified

• cargo fmt --all -- --check is clean, and so is cargo clippy -p framework_lib -- -D warnings
• cargo check passes for Linux, Windows, FreeBSD and UEFI (--features uefi)
• cargo doc with RUSTDOCFLAGS=-Dwarnings is clean
• cargo test -p framework_lib: 45 passed, 0 failed
• The CLI output is unchanged. The old and new threshold formatting paths produce identical strings for 0..=100000 K plus the edge values.
• Added four tests for the decoding, power.rs had none before.

Two things I could not check locally, both because I develop on macOS, which this project doesn't target: clippy on framework_tool (its libusb1-sys dependency needs a Linux C toolchain to cross-compile) and the EC reads themselves, since no machine here is a Framework one. CI covers the first. For the second, worth running --thermal and --thermalget once on real hardware before merging.

Scope

I stopped at thermals because you said that file was the messiest and @mysticmalard mentioned it was where they were headed next. The same treatment still applies to print_sensors, print_switches, get_and_print_power_info, get_and_print_pd_info, get_and_print_cypd_pd_info and the print_fw{12,13,16}_inputdeck_status methods.

Happy to keep going if this shape looks right to you.