Figure out how to use polling systems outside of WSTP and `IO`

Currently the only place you can materialize a PollingSystem is the work-stealing threadpool. Furthermore, all of our polling interfaces are currently in terms of IO and to get a hold of one you need an IORuntime.

Why do we care? Even if we are in IO on the WSTP, it might have the wrong kind of polling system installed, so we need some kind of fallback. Additionally, FS2 has promised Network and friends for any Async effect so we need to consider how to keep supporting that without having to maintain a handful of separate implementations that effectively do the same thing ...

I think these problems are somewhat orthogonal, but I suspect they are best solved jointly. Specifically we need:

1. a way to materialize a polling system on a "selector thread"—some sort of single-threaded event loop that just does I/O polling.

2. a way to use our polling interfaces from a non-IO effect

Controversial idea: for (1) just make a WSTP with one thread. For (2) keep using IO and use a Dispatcher to implement LiftIO[F] for arbitrary Async[F], similar to what Doobie does. This would work, and is arguably no different than using an NIO2 / Netty selector thread with CompletableFuture / ChannelFuture. Same deal: someone else's event loop with someone else's coroutine.

Follow-up to:

• https://github.com/typelevel/cats-effect/pull/3332

Start by reading the PollingSystem, WSTP, IO, IORuntime, Dispatcher, LiftIO, and Async interfaces, then review the linked follow-up pull request 3332. The work is complete when polling can be materialized on a selector thread and the polling interfaces can be used from a non-IO effect without maintaining separate implementations.