extend API to allow more kinds of concurrent access

[slingamn]

Context: autobrr/autobrr#1239 (comment)

I decided against some of the goals there (for example, being able to stop, reconfigure, and restart the connection is a non-goal now). I want to keep the linear lifecycle (Connection goes from stopped, to connecting, to connected, possibly to sleeping in between reconnections, and then finally to quit / perma-stopped), but with some changes:

1. It should be possible to query the state of Connection at any point in this lifecycle (probably need to add an exported enum describing the states)
2. Connection should be in a valid state before the first (*Connection).Connect has completed (or before it has been called at all); no methods should panic on an out-of-order call here
3. The connection maintenance loop should start automatically; Loop() will still be provided as a compatibility alias but the preferred name for the new functionality (block until Quit() is called) will be Wait()
4. It should be possible to block until the connection is actually stopped. (We need a new QuitTimeout after which we forcibly close the socket.) Multiple concurrent Wait() operations should be possible, thus making it safe to Quit() and then Wait() from any goroutine.

[slingamn]

We should fix #100 as part of this work

[slingamn]

Concurrent calls to Connect() (or Reconnect()) should be safe (only one should succeed). A Reconnect() call that happens-before the first Connect() call should probably just become a Connect().