Introduce higher-level "network client" APIs

FS2's Network APIs are frequently used to build clients such as Ember (HTTP client) and Skunk (Postgres client). These implementations build on top of the "low-level" Socket APIs and introduce higher-level concepts such as persistent, pooled connections. Currently there is both duplicated code and duplicated (and also unique!) bugs across Ember and Skunk and probably other client libraries in our ecosystem.

• https://github.com/typelevel/skunk/issues/266
• https://github.com/typelevel/skunk/pull/919
• https://github.com/typelevel/skunk/issues/1042
• https://github.com/typelevel/keypool/pull/518
• https://github.com/typelevel/skunk/issues/524
• https://github.com/http4s/http4s/pull/6980
• https://github.com/typelevel/keypool/issues/440
• https://github.com/http4s/http4s/issues/7216
• https://github.com/http4s/http4s/pull/7853

I propose that we introduce to FS2 a new set of high-level APIs that formalize "Connection" and help handle its lifecycle within a configurable pool. The goal would be that this abstraction is something that Ember, Skunk, and other client libraries could build on top of.

Start by reading FS2's existing Network and Socket APIs, then compare the linked Ember and Skunk implementations and related issues and pull requests. Define the shared Connection lifecycle and configurable pooling requirements before identifying the API boundaries. Done means FS2 provides a reusable high-level abstraction that client libraries can build on.