Add support for other native transports - io_uring and kqueue

Can I request a kqueue backend? It looks to me pretty simple tack on since we already have an epoll interface defined. Also, I should mention, while employing :epoll? true we should let people know they need to include [io.netty/netty-transport-native-epoll "4.1.36.Final"] or a matching version of said transport that matches the Netty version utilized, for kqueue: s/epoll/kqueue.

There is also uring_io coming soon https://netty.io/news/2020/11/16/io_uring-0-0-1-Final.html

Updating this issue for future reference. kqueue is nice to have, but macs/BSDs are less common as servers. io_uring support is of more interest for production purposes.

• [ ] Update code to choose transport from a set. E.g., :transport :io-uring instead of things like :epoll? true
• [ ] Support :epoll? flag for backwards compatibility, but have new :transport option override it. Document this.

Either:

• [ ] Add all necessary transport deps (~330kb)
• [ ] Add docs and errors directing users how to add manually when not present

Also see #480 for some unmerged work as a reference, but note that I don't want to add a kqueue? flag.

Be sure to check if io_uring actually provides an advantage before you commit time and effort to adding it. (When I checked early last year it actually performed worse than epoll on many tests. That might've changed in the time since.)

@valerauko Thanks for sharing your experience with io_uring. Hopefully this PR will be small, so it shouldn’t matter too much. 🤞

Once the documentation improvement will be merged, I'm going to work on this.