Give run_in_worker_thread a semaphore= argument

[njsmith]

If you want to limit the number of simultaneous threads, a semaphore is good for that. But right now it doesn't quite work with run_in_worker_thread(..., cancellable=True) because you lose track of the thread once it's cancelled. The idea here would be that if cancelled then run_in_worker_thread returns immediately... but the semaphore doesn't get released until the thread actual exits.

[njsmith]

Might make more sense to have it accept an arbitrary async context manager that we enter on the way in and exit on the way out. (Example use case: want to acquire two semaphores, to enforce both a global and local limit like in #6 (comment).) Or could even accept a tuple of async context managers, just like how with accepts multiple comma-separated context managers.with= would be a good kwarg name, but unfortunately is a syntax error :-). Maybe limiter=?

[njsmith]

Instead of supporing arbitrary async context managers, I think we should support arbitrary objects that have await obj.acquire() and obj.release(). The advantages are (1) the context manager exit protocol is quite complicated when it comes to exception handling and we don't need any of that here, (2) this makes the release a synchronous operation, which turns out to be very useful because the return-to-trio code runs in synchronous context and it seems silly to spawn a whole Task just to call some synchronous __aexit__ methods.

And let's say it takes values None, a semaphore, or a tuple of semaphores; None means to use the default semaphore and if you want completely unconstrained thread spawning you should explicitly pass an empty tuple.

(It also occurred to me that it might make sense to use a threading.Semaphore rather than trio synchronization primitives, since we have a thread here anyway, and it would simplify exception handling during cleanup. But this is a bad idea, because it would mean spawning a thread and then waiting for the semaphore, while the whole idea here is that we want to limit the number of threads that are alive at any given time.)

[njsmith]

This got fixed in #181, not sure why GH didn't close it.