feat(bsp): Add Kconfig configuration for the BSP components interrupt task

[finger563]

Description

Each BSP component that owns an espp::Interrupt previously hard-coded (or defaulted) the interrupt handler task's priority and left it unpinned, with no way to change them without editing the component. This adds two Kconfig options per component, wired into the espp::Interrupt's task_config:

• <PREFIX>_INTERRUPT_PRIORITY — int, range 0 25, FreeRTOS priority of the GPIO interrupt handler task (0 = lowest).
• <PREFIX>_INTERRUPT_CORE_ID — int, range -1 1, core to pin the handler task to (-1 = not pinned).

These are wired as .priority = CONFIG_<PREFIX>_INTERRUPT_PRIORITY, .core_id = CONFIG_<PREFIX>_INTERRUPT_CORE_ID in the Task::BaseConfig (placed after stack_size_bytes, matching the struct's field order).

Defaults preserve existing behavior:

• byte90 and t-deck previously hard-coded .priority = 20, so their ..._INTERRUPT_PRIORITY defaults to 20.
• All other components default to 0.
• Every component defaults ..._INTERRUPT_CORE_ID to -1 (unpinned), matching the prior behavior.

Components updated (15):
byte90, esp-box, esp32-p4-function-ev-board, esp32-timer-cam, m5stack-tab5, matouch-rotary-display, motorgo-mini, qtpy, seeed-studio-round-display, smartpanlee-sc01-plus, t-deck, t-dongle-s3, ws-s3-geek, ws-s3-lcd-1-47, ws-s3-touch.

Motivation and Context

The interrupt handler task runs all of a board's GPIO callbacks (buttons, touch INT, etc.). Depending on the application, users may need that task to run at a higher priority (so input is serviced promptly relative to their own tasks) or pinned to a specific core (to keep it off a core doing latency-sensitive work). Until now those values were baked into each BSP. Exposing them via Kconfig lets users tune the handler task per project without modifying the component, while keeping the previous behavior as the default.

How has this been tested?

• Environment: ESP-IDF v6.0.1, macOS host.
• Verified every one of the 15 components has both new Kconfig options and both corresponding task_config fields.
• Verified the designated-initializer order (stack_size_bytes → priority → core_id) matches Task::BaseConfig in all components.
• Confirmed byte90 and t-deck keep priority default 20; all others 0; all core_id default -1.
• Built esp32-p4-function-ev-board (target esp32p4) and esp-box (target esp32s3) examples clean.

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

N/A

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud buil
• All new and existing tests passed.
• My code follows the code style of this project.

[github-actions]

✅Static analysis result - no issues found! ✅