[nRF52] Implement SPI Component Support for Nordic Platforms

[aalaei]

Describe your core improvement

I am proposing the implementation of the SPI Bus component for the nRF52 platform.

With the recent successful integration of Zigbee and I2C support for nRF52 (via the nrfx SDK drivers), the platform is becoming a powerhouse for low-power sensors. Adding SPI support is the final "missing link" required to enable high-impact peripherals—specifically e-Paper displays (EPD), which are a perfect match for the nRF52's ultra-low-power profile in Zigbee networks.

The implementation should follow the pattern established in the I2C PR (#8150), wrapping the nrfx_spim driver into the standard ESPHome SPIComponent interface.

Current limitations

Currently, users of nRF52 boards (like the nRF52840 or nRF52832) can use I2C sensors and Zigbee, but are completely unable to use any SPI-based hardware.

Specifically:

No E-Paper Support: E-Paper displays require SPI. Since nRF52 + Zigbee is the ideal combo for "battery-powered status displays," the lack of SPI prevents this major use case.

Component Fragmentation: While the core e-Paper components exist in ESPHome, they cannot be compiled for nRF52 targets because the underlying SPI bus abstraction is missing for this architecture.

Technical benefits

Hardware Parity: Brings the nRF52 platform closer to parity with ESP32/ESP8266 within the ESPHome ecosystem.

Ultra-Low Power Displays: Enables the creation of Zigbee-based "Paper Dashboards" that can run on coin cells for months, leveraging the nRF52's superior sleep currents compared to ESP32.

Additional context

No response