Bluetooth: host: l2cap: trigger SDUs that get lost in limbo

Turns out the [first bugfix] was too naive: there is a case where resuming
all channels will not work on all queued SDUs, and the work handler will
give up and wait for the next sent SDU instead of trying to resume again.

This happens when the number of credits and conn contexts is very low for
the amount of data to send.

Always reschedule with a delay to avoid that situation.

[first bugfix]: https://github.com/zephyrproject-rtos/zephyr/pull/50476



Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>