dht: capture response and data in one critical section

[StanislavNikolov]

The first DHT22 read on an ESP32 could fail with checksum mismatch while subsequent reads succeeded.

waitForDataTransmission returns when the sensor starts the first data bit's low pulse. The subsequent call to receiveSignals and its interrupt setup consume part of that pulse. Since decoding compares each high pulse with its preceding low pulse, this can leave the first bit close to the decision boundary.

Wait for the sensor response inside receiveSignals, after disabling interrupts, then capture the data immediately. Return NoSignalError on response timeouts and restore interrupts on every exit. Remove the unused response-wait helper.

Validation:

• make test passed, including formatting, unit tests, and all smoke builds.
• An additional DHT22 program built for esp32-coreboard-v2 with -opt=1 -no-debug.
• Hardware: ESP32-D0WDQ6, DHT22 on GPIO27 with a pull-up, TinyGo 0.43.0, -opt=1 -no-debug.
• Original driver: the first read failed, followed by four successful reads, both before and after enabling BLE advertising.
• Instrumented reads: first-bit low/high loop counts changed from 99/98 to 183/87. All ten reads with the change passed. These are software loop counts; instrumentation itself affects timing.