Dispatch interrupts asynchroneously

This patch-set changes interrupt dispatching to happen asynchronously. This is a first step towards making API-calls interrupt safe. It also makes Epicardium more robust against a buggy payload as such a payload can no longer deadlock tasks which try to send interrupts (in such an instance, now they will be scheduled but never leave the IRQ queue).

Patch-List:

chore(interrupts): Make api_interrupt_trigger() return void

api_interrupt_trigger() cannot fail except by a programmer error (passing an invalid ID) in which case we should raise an assertion. Thus, make it return void instead of int.

fix(lifecycle): Don't trigger a reset during startup

This is a silent issue which I noticed during work in this patchset; we are sending a superfluous interrupt during boot. This patch changes this although it reduces readability of the code. I'd be ok with dropping it again if readability here is more important.

chore(interrupts): Move api into an epicardium module

Our buildsystem prevents implementing the task in epicardium/api so I moved the interrupts API into an Epicardium module.

chore(interrupts): Fix all modules to use new api

Update code-base to use new API.

feat(interrupts): Dispatch interrupts asynchroneously

Instead of blocking the triggering task when core 1 is still busy handling the previous interrupt, offload interrupt dispatching into a separate task. This is the first step towards making API-calls interrupt safe.

Next to the async triggering, the synchroneous mechanism is retained for special cases where async does not work (e.g. because of spin-locks). Currently, there is only one such case when resetting core 1 (triggering EPIC_INT_RESET).

docs(interrupts): Document new interrupt dispatcher task

Docs ...