Don't block UDP on ARP

[Felix-El]

I find it problematic to run a busy-loop while waiting for transmission or timeout at the end of UdpSocket::send().
My expectation would be that execution can continue and the next attempt to send data could return WouldBlock.

I'm aware this way we probably lose the ability to tell it timed out at all but is nothing that I count on as UDP is not
reliable anyway. Also in POSIX OS you get this kind of feedback only by special out-of-band message channel (recvmsg manpage).

Unfortunately, this causes API to change somewhat.

What are your thoughts on this?

[ryan-summers]

I do not use UDP at all, but based on some other reports, the UDP API is very problematic (#42), so I'd be happy to see any kind of cleanup here.

In general, I'm fine with having the data queued for transmission with the W5500 and changing the API, that would make this driver much more compatible with async-like approaches.

[elpiel]

@Felix-El I've thought about a few improvements that should make things much better:

1. Include the possibility to use the Interrupt pin, then only when the interrupt pin gets triggered you can look at the interrupt and decide what should be done (or if a send has finished for example)
2. Have a non-blocking async API which by default have await point that will not block the device

Returning WouldBlock on send, might also be problematic as you might need to busy-loop then in order to send a new packet. Not sure what a good approach would be but I'm opened to discussions.