Make this package transport agnostic

[briansorahan]

Problem

OSC is an encoding, not a protocol.
See Adrian Freed's comments here: https://forum.pjrc.com/threads/18849-Open-Sound-Control
It would be nice to be able to use this package with networking protocols as well as serial.

I'm opening this issue as a way to jot down my ideas about how to do this.

Solutions

1. Encoder/Decoder

We let users provide their preferred io.Reader or io.Writer implementations and encode OSC packets using those.

Advantages

Simplicity

The code in this package could be very clean and concise, truly transport agnostic.

Disadvantages

Sender information

Anytime I write a method that replies to the sender I use the Sender field of the Message type, which is a net.Addr that we get by using ReadFromUDP.

If we go this route then this would have to change (possibly requiring updates to a lot of code).

One idea is to change Sender to an io.Writer. If this feels right in practice then this might make it worth updating everything out there right now that depends on Sender being a net.Addr.

Usability

It might make some people feel that the package is to hard to use if they have to initialize their own io.Reader or io.Writer. Maybe this shouldn't be a big concern because most Go programmers are probably familiar enough with the standard library to not care too much.

2. Conn types

We already have UDPConn.

We could just add TCPConn to round out network protocol support.

And maybe USBConn for serial connections.

Advantages

Package consumers don't need to write as much code.

Disadvantages

We have to maintain more code. We'd probably end up implementing the Encoder/Decoder solution internally anyways.

[avlapp]

Interesting thoughts. See also: https://www.cs.cmu.edu/~rbd/papers/o2-icmc-2022.pdf
At the moment there isn't a golang osc library with implemented/ supported TCP support it seems.