Bind "IRQ handlers" to GPIO pins

[bugadani]

Second attempt at this.

We now register interrupt handlers on-demand. Surprising behaviour may be:

• The GPIO interrupts are handled at the maximum configured level. This is probably the point I have the most issues with.
• Calling async functions overwrite any configured interrupt handlers. As an alternative, we could try restoring the handler, keeping both handlers in parallel and re-enabling the IRQ, or simply panicking if a user handler is set. I'm undecided, but "replace and keep working" is as equally valid a strategy as any.
• There is no way to globally replace the IRQ handler using runtime binding. I don't find this a big negative.

All documentation is missing because it wasn't necessary to demonstrate the idea.

cc #2009

[Dominaezzz]

Hmm, I have a vauge feeling this won't play nicely with this idea. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/intr_alloc.html#iram-safe-interrupt-handlers .

There should be some way to force users to choose a single priority from the start.

[bugadani]

I'm slightly afraid "the priority you set here will be ignored" isn't what we are aiming for, but it's something to consider.

[Dominaezzz]

Or perhaps this shouldn't take InterruptHandler as a parameter? Since this isn't a real interrupt and that way there's nothing to ignore here

[MabezDev]

Sorry I haven't looked at this yet, I still need to think about this some more. Particularly, "The GPIO interrupts are handled at the maximum configured level" seems like a recipe for confusion, but I need to spend a bit more time thinking about what kind of footguns this may or may not cause in reality.

[bjoernQ]

I see how this can be convenient for the user - probably I'd prefer the user to not pass an InterruptHandler but a plain function and setting the priority separately

However, I think we want the user to be able to register a custom global GPIO handler - especially via enable_direct in case they need low latency (haven't measure but this adds a little bit of additional latency)

Mabe I'm missing something and it's possible but unfortunately this PR contains quite some "noise" so maybe I'm wrong

[bugadani]

Users can use esp_hal::interrupt::bind_interrupt I believe if they need to.

[bugadani]

As for "take a function pointer", there's #2110 (comment) . On one hand, there's API consistency (and convenience by doing things automagically). On the other, there's the need to not be confusing, but without some priority we can't late-bind the gpio handler like this PR tries to do.

We can set the priority in the Io constructor (or .pins() in this PR) but setting the priority of an unbound interrupt handler seems funny to me and may be problematic with RTIC still.