Minor: inaccurate async sensor module docs, crate version drift, no blocking ThresholdWait counterpart

Collected minor observations from an API review. Splitting out if any of these turns out to be non-trivial.

1. embedded-sensors-async/src/sensor.rs module docs are inaccurate

The module header says it "contains traits generic to all sensors", but the module only re-exports Error, ErrorKind, ErrorType and the decl_threshold_traits! macro from the blocking crate. There is no Sensor trait. Either reword the docs or introduce the trait the docs imply.

2. Version drift between the two crates

embedded-sensors-async/Cargo.toml depends on embedded-sensors-hal = "0.1.0" while the workspace member is at 0.1.1. The workspace [patch.crates-io] entry masks any drift for local builds but not for published artifacts. Worth keeping the dependency requirement in sync as part of the release process.

3. Blocking crate has no polling counterpart to ThresholdWait

Not necessarily a defect - blocking code can simply re-read the sample - but if a *ThresholdPoll or an alert-pin-status method is ever wanted, it is easier to add before 1.0.

Start with embedded-sensors-async/src/sensor.rs and compare its module documentation with the re-exports it contains. Then inspect embedded-sensors-async/Cargo.toml and the workspace patch configuration for the crate version requirement; review ThresholdWait before deciding whether a blocking polling counterpart belongs in scope. Done means the selected observations have an agreed scope and the documentation and dependency metadata are consistent.