Proto-layer endpoint/connection communication

[Ralith]

Gives us freedom to adopt more specialized communication strategies (e.g. atomics or fine-grained locks) between endpoints and connections. These will need to be implemented at the proto layer, because optimal strategies will be sensitive to the specific data proto-private being communicated, e.g. NeedIdentifiers as an atomic counter.

Simplified take on #1650, pushing cheeky data structures to future work.

[djc]

Do you mind writing a more detailed description of how this PR makes this more modular? I skimmed the commits but the new structure (or, how the structure changes) is still a bit hazy.

[Ralith]

The main effect of this PR is to replace the requirement that quinn-proto users pass endpoint and connection events around themselves with the requirement that users trigger wakeups when events have occurred, with quinn-proto managing the actual message-passing internally. This is not necessarily more modular, but could be useful because it allows future work to replace naive message-passing with more specialized structures as in #1650. A more specialized communications structure could be lighter: an AtomicUsize counter is much lighter than message-passing for requesting new connection IDs and has constant memory overhead, for example. We still need to dispatch wakeups, but unlike messages, those are idempotent and hence don't need to be buffered, which might simplify downstream code.

It's not obvious that the benefit here is significant as it stands. quinn wasn't simplified, because it still needs the same channels for other purposes. Perhaps those can be addressed in future work; e.g. quinn::ConnectionEvent could probably be reduced to a set of shared flags.

My real goal is to work towards fine-grained interior mutability in quinn-proto, particularly Endpoint, to eventually support parallel endpoint drivers. I don't think this PR moves us in that direction.

This is also a step towards resolving #1131, but the real substance of the hazard described there is in handling datagrams, which is unchanged, and could be addressed without this PR.

This effort was ultimately exploratory, and I'm open to shelving it until it's more strongly motivated.