ESP-IDF build: give Panel_LT8912B the M5Unified headers when that component is in the build

[ainyan03]

What

Panel_LT8912B (the PoE-P4 display output board) talks to the bridge through M5Unified I2C_Class, picked up with __has_include(<utility/I2C_Class.hpp>). In an ESP-IDF component build that header was never on this library's include path, so the display output always failed at init with M5Unified I2C_Class is not available. Arduino builds pass every library path to every library, which is why it worked there.

The M5Unified component's source directory is now added as a private include directory whenever such a component is part of the build, in the same way the Arduino component is picked up (M5GFX_M5UNIFIED_COMPONENT=<name> to override, =OFF to disable; several candidates at once are rejected like the Arduino case). The symbols resolve at link time because ESP-IDF links the component libraries as one group.

Checked

• Unit PoE-P4 (ESP32-P4 v1.3) + display output board, ESP-IDF 6.1 direct build: before, displays=0 with the message above; after, the output comes up at 1280x720 and refreshes.
• Arduino core 3.3.9 build is unaffected (no CMake involved).
• Fork CI (ESP-IDF build) green.

Note on the dependency

This does not add a dependency of M5GFX on M5Unified. Panel_LT8912B has two ways to reach the bridge: through an m5::I2C_Class the application passes in (M5Unified passes its already-open internal bus so the port is not opened twice), or through an ESP-IDF I2C bus it opens itself from i2c_port / i2c_sda / i2c_scl when no I2C_Class is given. The first path is compiled only when the M5Unified header is visible; this change makes it visible in ESP-IDF builds that already contain M5Unified, which is the case where M5Unified hands over its bus.

[ainyan03]

Superseded by #290: Panel_LT8912B now reaches the bridge through lgfx::i2c, so the include path from M5Unified is not needed at all. Closing.