rtio: Poll mode

[teburd]

Is your enhancement proposal related to a problem? Please describe.
Not every I/O peripheral is best suited to be driven by interrupts and at times polling is the best option. Being able to move work out of the submit call avoids deep call trees and enables hardware polling for I/O completion or incrementally moving states in a state machine an I/O device (iodev) may internalize.

Describe the solution you'd like
The idea is that on submit if the iodev needs to be polled it adds itself to the contexts poll queue. This poll queue is then iterated over at some point in the future. This iteration could be done in a timer ISR, a dedicated thread, a work queue task, or any other sort of delayed future work sort of setup. That includes doing it directly in line after something like rtio_submit with a blocking wait count is called or rtio_cqe_consume (blocking or not) is called.

No specified polling iterator is setup here as its not clear what the best option, if there even is a best general option, would be.

A use case in tree today is the sam spi driver which may best be served by doing blocking spi transcieves for small transfers which does not make sense to setup interrupts for. In this scenario a small transfer request would result in the iodev adding itself to the poll queue, and only performing the transfer once polled. Further polling the SPI peripheral registers and moving the transfer forward each poll call. In effect it would externalize some of the looping that occurs in transceive.

This way rather than blocking on submit (which is wrong) the work is effectively shoved off until it makes sense to do it in the poll call. Each device may break up the blocking work into multiple steps, e.g. poll hardware registers, move the work forward, repeating until completion.

As an added benefit this removes the deeply nested call tree that could result from a blocking call like this, where submit blocks, does work, and calls complete, resulting in more work perhaps being started for the same iodev (inadvertent recursion/deep call stack).

Additional context
Small PR that added the API but did not fully implement it.
#62605