USB next stack: make SOF events optional

[benedekkupper]

Is your enhancement proposal related to a problem? Please describe.
USB SOF events are only relevant to a specific subset of USB functionality (mainly isochronous transfers), and serve no purpose in other use cases (e.g. input devices, comm ports, mass storage). Servicing these events even without any downstream consumers (interrupt in every 1ms, dispatched to UDC thread, then dispatched to USBD thread) does consume a considerable amount of CPU time, that could otherwise be spent on application threads, or in low power mode.

Describe the solution you'd like
I can imagine two different solutions:

1. SOF event delivery is tied to a Kconfig option (a user configured USBD option, that assigns the separate UDC option). This has the advantage of even saving the code space needed for SOF event delivery.
2. SOF event delivery is runtime configured, where each USBD class driver can request SOF events, and the USBD core keeps track of how many SOF consumers it has, if it's positive, SOF is enabled, if it drops to 0, SOF is disabled.

edit: this feature could reduce the rate at which bug #74058 (which is a serious problem that can only be remedied by a full software reset) manifests.

[github-actions]

Hi @benedekkupper! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[henrikbrixandersen]

This was brought up before in #76073 (comment)

I share the concern with the added CPU load for handling SOF interrupts even when they are not used.