Write some docs explaining our thread pool philosophy

[njsmith]

Basically: most systems use fixed-size thread pools for two reasons: (a) re-using threads is cheaper than spawning new ones, (b) you need some sort of global control over thread spawning to avoid accidentally overwhelming the system with getaddrinfo calls (or whatever). The problem with combining these though is that if you only have a single fixed-size thread pool for the whole system then that creates this global synchronization that can lead to deadlocks (see #6), so then you make multiple thread pools, but now you're doing a poor job of re-using threads...

So our philosophy is: there's an underlying run-in-thread primitive that might re-use threads for efficiency (currently it doesn't, but likely will sooner or later), but it acts as an unbounded thread pool. Then we layer the capacity control on top of that as a second layer, which allows for complex policies, multiple "virtual" thread pools that share the same underlying pool for efficiency, etc.

It's not that groundbreaking, but it's not how people usually think about these things so we need some conceptual-level documentation.