Add control_UDP node

[wisecg]

This PR adds a new type of control node, UDPNode, with a design similar to (but simplified from) EthernetNode.

We add UDPNode to support devices communicating via connectionless datagrams (socket.SOCK_DGRAM), as the existing EthernetNode strictly implements connection-oriented TCP (socket.SOCK_STREAM).

Context:
Mason and I have been using UDP packets for many new sensors on the VDG. The following summary is from him:

In the beginning stages of our data acquisition renaissance we decided that UDP was the best method for our networked sensors to send data to our SlowDash server. This protocol was chosen only for diagnostic sensors (show hardware health) and NOT process sensors (trigger critical events).

Pros of using UDP

• Client devices can send without an error endlessly even when nothing is listening so they are always ready to go when a listener is set up
• Network and power interruptions do not need to be addressed, the device will just continue sending when power or the network is available again
• Packets are lightweight and meant to keep as much bandwidth available for other devices
• Each new sensor controller connection does not require a new connection

Cons of using UDP:

• Besides ping, there is no evidence of a sensors life if it is not sending data
• A specific port (socket) must be bound in the server software
• No guaranteed delivery or ordering of packets

[SanshiroEnomoto]

Thank you! I can merge this as is, but SlowDash naming convention for the control node class is to use the Pascal case, capitalizing only the first letter even if it is an abbrivation (as commonly done in JavaScript, Java, C#/.NET, Swift, Kotlin, ...). So if you want to follow the coding style, it should be UdpNode. Maybe a better would be UdpSocketNode? Please let me know you want to keep the current name or change it.

[wisecg]

Thanks for the suggestion -- I have changed the name of the class to UdpSocketNode (and left the filename intact).

[SanshiroEnomoto]

Thanks!