Make set_interrupt panic free

[bjoernQ]

set_interrupt implementations can panic because Priority contains the None variant.
IIRC we use it internally for disabled interrupts so we cannot just remove it (also we transmute there - need to be cautious about that!)

One way would be to have an internal / HW priority and a user-facing priority - the later wouldn't include None (other solutions are also possible)

[bugadani]

The Xtensa interrupt_level_to_cpu_interrupt also returns an error if you want to set an edge-triggered interrupt at Priority2. Not sure what we can do about that, and this may be relevant for ESP32 and S2.

[bugadani]

Also, exposing Priority::None is interesting in combination with #2684 - although I'm not sure if doing that makes any more sense than using a RefCell in this particular case.

[jessebraham]

Why is this a 1.0 blocker if we do not plan to stabilize interrupts?

[MabezDev]

Whilst we aren't stabilizing the interrupt module, drivers in blocking mode should be able to set a interrupt handler. As it turns out, they can't right now: #2905. Once that's fixed, it becomes a bit more clear why this is a 1.0 blocker.

This has also made me realize we do need to stabilize some things in the interrupt module, namely Priority and InterruptHandler.

[bugadani]

This has also made me realize we do need to stabilize some things in the interrupt module, namely Priority and InterruptHandler.

What about the #[handler] macro? While we don't need it stable, it's probably good enough in its current form to be stable, unless you have concerns?

[MabezDev]

As per #2900 (comment) we're not planning to stabilize interrupts, therefore I'm removing the 1.0-blocker label