@starbeam/peer and frames

[wycats]

As I mentioned in 0b534b4, we intend for @starbeam/peer to be the stable way that multiple versions of Starbeam can coexist in a single process.

Exposing now and bump solves the problem for cells versioning, which covers a lot of ground, but it doesn't cover consumption, which is necessary for full interoperability.

On the bright side, this problem only comes into play once we make a post-1.0 breaking change, but we should sort it out before 1.0.

Roughly speaking, we want to design a minimal API for consumption that can cover both consuming cells and frames, but without sucking in the whole design of TIMELINE, which is actually a pretty good candidate for breaking changes.