Log setup()/update() timing, matching epaper_spi's "Display update took" line

Both calls block synchronously on the panel's busy pin for as long as
a real refresh takes, which explains why boot's dump_config() log
lines can appear to stall - setup() runs (and blocks on GxEPD2's own
init/clear cycle) for every component before dump_config() runs for
any of them. This is esphome-level timing only, not a peek at gxepd2's
internal state.

components/gxepd2/gxepd2_display.h

@@ -92,15 +92,27 @@ class GxEPD2Display : public display::DisplayBuffer {
     }
     this->spi_.spi_setup();
     this->driver_->epd2.selectSPI(this->spi_, SPISettings());
+    // GxEPD2's init() does a real panel clear/refresh, blocking on busy just
+    // like update() does below - it runs during ESPHome's synchronous
+    // setup() phase, before any component's dump_config() is called, which
+    // is why the whole boot log can appear to stall here.
+    uint32_t init_start = millis();
     this->driver_->init(0);
+    ESP_LOGD(TAG, "GxEPD2 init took %u ms", (unsigned) (millis() - init_start));
   }
 
   void update() override {
+    // GxEPD2 blocks synchronously on the panel's busy pin for the whole
+    // call below - this isn't peeking at gxepd2 internals, just timing the
+    // one call from the esphome side, to make that stall visible in the log
+    // instead of it looking like the main loop silently hung.
+    uint32_t start = millis();
     this->driver_->setFullWindow();
     this->driver_->firstPage();
     do {
       this->do_update_();
     } while (this->driver_->nextPage());
+    ESP_LOGD(TAG, "Display update took %u ms", (unsigned) (millis() - start));
   }
 
   void dump_config() override {