feat(dmac)!: add Interrupts type parameter to DMA channels

[QuartzShard]

Summary

Follow on from #977: Adds a new Typelevel enum Interrupts with states Available and Blocked. This gates enable_interrupts and associated methods so that a Blocked channel cannot change interrupt configuration.

This allows the implementation of From<> to convert Async-mode channels (ReadyFuture), into Sync-mode channels (Ready) (and vice versa) to permit the use of Transfer when the controller is configured in Future mode - without risking Incorrect behavior why conflicting with the ISR that the async DMAC uses. My motivation for this was requiring both async usage for UART and a Circular transfer for reading from a DVP camera - but a ReadyFuture channel cannot function with the Transfer api.

Checklist

• All new or modified code is well documented, especially public items
• No new warnings or clippy suggestions have been introduced - CI will deny clippy warnings by default! You may #[allow] certain lints where reasonable, but ideally justify those with a short comment.

[QuartzShard]

Failing on clippy::type_complexity lint, would like advice on how to address.
The pattern Transfer<Channel<Ch::ID, Busy, Ch::Interrupts>, BufferPair<B, Self>> shows up in a few spots, and with the new param, upsets clippy. Is this a valid ignore, or should an alias be introduced?

[rnd-ash]

I guess introducing a type alias for a Busy channel with Interrupts should work, since a similar concept exists for other peripherals, just not sure what to include exactly in the type Alias...

[QuartzShard]

I'm happy with the state of this now - finished with janitorial docs stuff

[QuartzShard]

I've been writing a Ring Buffer on top of this, both to actually use and as a stress test of the API, and on reflection, I am not convinced this is the correct approach.

The main point of contention is that the current ISR for the Async DMA unconditionally disables channels when TCMPL fires, which is correct for one-shot channels (which is the entire current story for async DMA). This is wrong for circular/linked transfers, which was what I was attempting to solve by disallowing the use of interrupts when the ISR would cause issues; But really, shouldn't the ISR be made less opinionated? The channel can be disabled in poll() for TransferFutures before returning Ready.

I'm thinking to either move channel management into poll calls, or make the disable conditional on a static CHANNEL_MODE: [AtomicBool; NUM_CHANNELS], which then makes all of this unecessary.