Remove the pipe protocol compiler

[brson]

Abstractions built on pipes are created using a 'protocol compiler' that can define complex interactions between two endpoints. At this point I think it is not worth maintaining, for several reasons:

• In practice we are using just a few simple pipe-based types and not defining custom protocols
• The protocol compiler imposes some maintenance burden. It is a complex syntax extension that generates many calls into core.
• Writing and maintaining protocols is hard, aren't that aesthetically pleasing.
• It is not likely to be further developed in the near-term

Instead I think we should rewrite the existing protocols by hand and remove the compiler.

[graydon]

In practice I don't think we've even transitioned off Channels and Ports terribly much yet, much less given this stuff a fair shake. I'd like to give this more bake time to see which parts are necessary, which parts overcomplex. We haven't written enough complex concurrent code yet to be clear on that yet. There are a lot of moderately-complex protocols I can imagine us wanting to have implementations for (those related to I/O, files, sockets, locks, databases, concurrency primitives) that it may be the best route for generating. Doesn't feel clear to me yet.

[bblum]

:(

[brson]

I'm still in favor of this. pipec continues to be difficult to maintain. Every time I work with or on pipes I am tempted to inline the stream and oneshot protocol expansions into core::pipes but I haven't yet.

[catamorphism]

Not critical for 0.6, de-milestoning

[thestinger]

Removed by #8170, the bug tracking a rewrite is #7668.