Remove BigPipeInterface and move all of its docs to the implementation

I think you're right, those had interfaces created for the sake of creating interfaces. There was a time when we were pretty much blindly extracting interfaces out of classes. Doing it blindly was probably wrong. But now we can't change that.

We can still extract an interface later — that's equivalent with adding an API. But we can never remove an API. Hence this approach makes sense.

A different angle:

• Those are subsystems, each providing an API designed to be used by just about every Drupal module. That highly increases the likelihood of swapping/extending their implementation. Because the API may need to be bent to deal with a particular edge case.
• BigPipe on the other hand provides no API at all. It consumes the Render API and the request processing API. The likelihood of swapping/extending its implementation is orders of magnitude lower. But it's still possible — you just have to subclass it.

Preferably, this gets committed after #2657684: Refactor BigPipe internals to allow a contrib module to extend BigPipe with the ability to stream anonymous responses and prime Page Cache for subsequent visits, because that one is much harder to reroll.

#2657684: Refactor BigPipe internals to allow a contrib module to extend BigPipe with the ability to stream anonymous responses and prime Page Cache for subsequent visits is in! Rebasing #2…

Oops, this is the right patch.

Yay, this unblocked #2797169: Mark BigPipe as stable/non-experimental!