Possible API breakers in ParkingLot

[njsmith]

See the big comment at the top of the file.

In particular:

• We might want to switch to a single global ParkingLot, in which case the API would shift quite a bit. (Instead of having ParkingLot objects, we'd have an argument which was an arbitrary id naming the synchronization object.)

• If we implement WFQ (Design: alternative scheduling models #32) then we'd probably need to stop returning the unparked tasks from unpark. (This would slightly complicate the implementation of RLock and Condition, but I don't think it's too bad.)

• We might want to add a way for tasks to mark themselves when parking, but probably this could be done in a backwards compatible way.

[njsmith]

I also wonder if we might want to remove the result= argument to unpark? I don't think anything actually uses it, and it also might complicate any scheduling experiments...