Improve the Tcp benchmark to show multi-executor performance

[glommer]

The "bandwidth over 100 sockets" test is only able to use two threads. Therefore it will not scale as well as Tokio and other frameworks. This is totally fine because a real application should use more cores but it would still be nice to see that scalability in the benchmark.

Aspects to consider when dealing with this:

• Is it better to have separate executors for accept or have an accept + connect task queues in each executor ? I suspect the latter but also need to make sure the connections all become CPU local making for an unfair benchmark

My intuition tells me that there has to be a good, ergonomic way to spawn similar work in all or a subset of executors. An outstanding implementation will do that first as a stepping stone but not a must.

[glommer]

See issue #237 from @zserik