tp: give the RPC layer one framing stream per connection

Rpc holds a single tokenizer for the whole process, even though several
transports serve more than one peer at a time. A tokenizer holds the
message that arrived in pieces, so interleaving the bytes of two peers
into one corrupts both.

unixd.cc had already worked around this by keeping a ProtoRingBuffer per
connection and forwarding only whole messages, and httpd.cc is about to
need the same thing: once it reads payloads straight into the tokenizer,
two connections mid-payload at once alias each other's memory.

Introduce Rpc::Stream, owning the framing state of one byte-pipe: the
tokenizer and the response function. Transports that serve one peer
(Wasm, stdiod) hold one stream; those that serve many (httpd, unixd)
hold one per connection. unixd loses its hand-rolled tokenizer and
message-forwarding loop, as the stream does that now.

The message sequence ids deliberately stay on Rpc, shared by every
stream. They are not framing state: a second peer numbering its requests
from its own 0 breaks the sequence, and that is how two clients on one
TraceProcessor - two UI tabs on the same --httpd instance, say - are
detected and told so. Per-connection tokenizers make that check more
useful rather than replacing it, because the peers now reach it with
their framing intact instead of first shredding each other's messages.

This also retires the SetRpcResponseFunction(fn)/SetRpcResponseFunction
(nullptr) dance every transport had to perform around each dispatch: the
response function is handed to the stream once, at construction.