Improve the organization of end-to-end protocol concepts

Broflake is in a bit of a weird state with respect to its end-to-end protocol. The egress server speaks QUIC, without any flexibility -- but at the other end, the Broflake clientcore library is quite layered and decoupled: you can create a "raw" BroflakeConn, which is like a net.PacketConn, then create your own reliable stream over it -- and we include a ReliableStreamLayer interface for doing exactly such a thing.

It's not great for comprehension that our ReliableStreamLayer interface lives in clientcore, but some future listener for it would probably be forced to live in egress. (Imagine if, in the Go standard library, dialers and listeners did not live together in the net package, but rather were spread across different packages.)

One option is to include these concepts in the common module, but that also doesn't make the most sense.

Maybe the future is to create a new module for e2e protocol concepts. This would logically be a place to implement different top level stream layers, if we find ourselves tweaking the protocols for performance enhancements. You might imagine a world where implementers contribute back some alternate top level protocols, sort of like pluggable transports.

Start by mapping the existing e2e protocol concepts across the clientcore, egress, and common modules, including ReliableStreamLayer and BroflakeConn. Compare where the QUIC egress implementation and clientcore abstractions belong, then define a module boundary for shared protocol concepts. Done means the organization and any alternate top-level stream-layer extension point are agreed and implemented.