Rationalize backend Semaphore interface slightly

[tomchristie]

Some internal refactoring, to make the usage of backend 'semaphore' and 'event' classes more consistent.

• Switch to create_semaphore() for consistency with create_event().
• Stop using BasePoolSemaphore, and instead just use a generic BaseSemaphore. Pass the exc_class=PoolTimeout, so that backend semaphores are not specific to any particular use-case. (We don't strictly need to do this, but I think it feels neater?)
• Move implementations into more consistent locations, so that event and semaphore implementations are kept close.

[tomchristie]

After this I'm planning on:

• Switching from using an Event in h2 to using a Lock instead. (So backends expose a lock implementation, rather than an event implementation.)
• Move read/write locks outside the stream, and onto the HTTP classes instead, with a view to resolving Write error on HTTP/2: "AssertionError: assert waiter is None or waiter.cancelled()" #551.
• Revisit Connection pool refactoring #624, which needs locking behavior to get fully sorted. (With a view to resolving Issuing requests in close concurrency can unneccessarily result in multiple HTTP/2 connections. #514)

[florimondmanca]

💯 Yes!