Reliable UDP transport when for unicast

**Describe the problem you have/What new integration you would like**
It should be possible to get optionally get reliable UDP transport when not using multicast addresses with the UDP component, by having target devices respond with ACK packets.

**Please describe your use case for this integration and alternatives you've tried:**

When using paired devices (i.e. presence sensor and a light) I generally want the light to come on as fast as possible. But most of the time a 1s rebroadcast rate of state which never changes is a waste of airtime for the device (or impractical if it is battery powered).

The UDP component provides a very ergonomic interface for these types of distributed components: if unicast devices could acknowledge receipt of packets, then devices could use much faster re-send times and then stop sending once the target device has acknowledged the state.

The other elements of UDP (i.e. encryption support) make this very appealing.

**Additional context**

The ability to receive replies from foreign devices would, ideally, also enable a more direct RPC protocol - i.e. remote invoking actions which would save from kludges like dummy binary sensors with toggle sensors

It would probably also be possible to have this work with multicast anyway - receivers would send an ACK packet to the source, and the source would maintain a list of receivers it believes should be acknowledging packets.

The issue identifies the UDP component but names no files, tests, or entry points. Start by locating that component and reviewing its unicast, encryption, and packet-handling behavior; define the ACK format, resend and stop conditions, and whether multicast is supported before determining how completion should be tested.

Written by the indexing model from the issue text.