This PR introduces a Reconnect middleware for WebSocket clients, a spiritual equivalent to the Retry middleware we have for HTTP Clients. The idea is to abstract away the retry and reconnect logic behind what presents as a single, persistent connection that withstands network hiccups. I have currently settled on a number of design choices intended to keep the implementation simple and modular.

1. The middleware actually applies to WSConnectionHighLevel instead of to WSClient. This enables the user to create their own retry logic for the connect action, see design choice (2).

2. Unlike the Retry middleware for Client, this middleware does not implement any sort of retry logic; it will simply attempt to connect again immediately. The expectation is that the user will employ e.g. cats-retry to the connect action to get backoff, etc.

3. In the same vein, the middleware does not retry failed sends or receives; it's up to the user to do that, likely with the help of cats-retry. The middleware simply guarantees that a new connection will have been established between the error and the retried send/receive.

One caveat of these design choices is that retrying the connect: Resource on error is currently complicated by an outstanding Cats Effect issue:

• Resource#attempt holds onto acquired resources even in case of error typelevel/cats-effect#3757

This issue doesn't affect either the JDK or http4s-dom WSClient implementations because they establish the entire connection within a single delay(...). But, this bug would cause the Ember WSClient that is WIP in #7261 to starve the pool of sockets upon retries. That's because in the Ember implementation, opening a WebSocket connection occurs in two phases: (1) acquiring a socket from the pool and (2) handshaking with the server. Currently, catching an error in phase (2) does not return the socket to the pool that was acquired in phase (1). In any case, I think we've decided this behavior is undesirable and will ship a fix in CE 3.6.