Added local queue scheduling and "next_task" optimization

[nullchinchilla]

Two major changes significantly improve performance:

• When Executor::run() is called, a handle to the local queue and ticker are cached into TLS. This lets tasks schedule to a thread-local queue rather than always to the global queue.
• Within the local queue, we implement a next_task optimization (see https://tokio.rs/blog/2019-10-scheduler) to greatly reduce context-switch costs in message-passing patterns. We avoid putting the same task into next_task twice to avoid starvation.

Through both unit testing and production deployment in https://github.com/geph-official/geph4, whose QUIC-like sosistab protocol is structured in an actor-like fashion that greatly stresses the scheduler, I see significant improvements in real-world throughput (up to 30%, and this is in a server dominated by cryptography CPU usage) and massive improvements in microbenchmarks (up to 10x faster in the yield_now benchmark and similar context-switch benchmarks). I see no downsides --- the code should gracefully fall back to pushing to the global queeu in case e.g. nesting Executors invalidates the TLS cache.

I also added criterion benchmarks.

[notgull]

@nullchinchilla Would you be open to rebasing/cutting down on this PR? These optimizations are important and I would be open to reviewing it.

[nullchinchilla]

I've actually decided on a different course, since I've realized that local scheduling and an unstealable next_task cell can cause issues (such as deadlocks if we nest smol::block_on).

You can check my latest executor work in the "smolscale" crate, which uses smol::Task as well and is fully compatible with the smol-rs ecosystem, but to be easier to optimize forces a global executor.

[notgull]

Thanks for letting me know! I think that this crate should act more as a "reference" executor, that aims to implement features rather than be as optimal as possible. I'll close this for now.