use a configurable amount of worker threads to handle requests

[sharksforarms]

instead of having a 1-1 mapping between application thread and neverbleed threads, we can configure a static pool of threads that can handle incoming requests.

Using epoll features, we can have an idle thread handle the next incoming request.

In summary, there is an epoll instance per thread. The client fd is added to each thread's epoll instance with EPOLLEXCLUSIVE, so that only a single instance will get woke when the fd is ready.

For offload events, we keep these on the same thread the offload request was started on, I found that offload requests cannot be resumed on a different thread, see intel/QAT_Engine#306

Other:

• removed the ability to set thread affinity (makes less sense when having a thread-pool vs 1-1 mapping with application thread)
• removed yield_on_read as we poll to see if the fd is still read-able