Move trio.Condition into trio.hazmat, or possibly remove altogether?

I was reading @bcmills' slides Rethinking Classical Concurrency Patterns (linked from here), and among other things it has a bunch of interesting discussion of condition variables and how tricky they are to use (starting on slide 37). It also led me to https://github.com/golang/go/issues/21165, where he proposed deprecating Go's Cond type entirely.

It's true, they really are stupidly hard to use correctly. The main arguments for them are (a) they're a very efficient low-level primitive that's often used to build higher-level tools, (b) they're extremely traditional and taught in every textbook, so people expect to have them.

In Trio, though, they really aren't very attractive. They're not particularly efficient, and we don't use them as a primitive to implement anything else – when you want a fast low-level finicky thing, you use wait_task_rescheduled instead. I've never found a situation where I wanted trio.Condition. They have weird semantics (there are only four uses of cancel shielding inside Trio, and one of them is in trio.Condition, and it's the only case that can create an uncancellable deadlock). And even if we do provide them, there's no particular reason they need to be in the top-level namespace. So I think the argument for at least moving Condition into trio.hazmat is pretty clear.

Should it exist at all? It's definitely a bit annoying to implement – there's a chunk of complexity in trio.hazmat.ParkingLot that's exclusively to handle Condition. (Specifically the stuff about fair requeueing between ParkingLots.) We don't even use ParkingLot nearly as much as I expected we would. It does need some tight integration with trio.Lock, so if you wanted to replicate it in a third-party library you'd probably need your own Lock implementation as well. (Or maybe this is only if you want to be finicky about fairness? I forget. Should figure this out.)

#637, the issue about deprecating Event.clear, is also closely related.

Start by reviewing the discussion around trio.Condition, trio.hazmat.ParkingLot, trio.Lock, and wait_task_rescheduled, along with the linked concurrency references and related issue #637. The work is done when the project has a decided disposition for Condition and the affected API and implementation scope is clearly identified.