protozero: let transports read directly into ProtoRingBuffer

Every transport kept a staging buffer, read into it, then handed those
bytes to Append(), which copied them again. BeginWrite()/EndWrite() lets
read(2) deposit them in the ring buffer directly, so they are copied
once.

The reservation is handed out as a move-only WriteHandle that must be
consumed exactly once, by EndWrite() to keep what was written or
AbortWrite() to discard it; dropping one fails a CHECK. Holding it in a
value the compiler tracks is what makes the pattern safe to use: the
buffer refuses to recompact, grow or hand out a second reservation while
one is outstanding, so bytes cannot move under a pointer someone still
holds. Rpc::RequestHandle carries the same contract out to the
transports.

Four bugs fell out of this, three of them a reservation abandoned on a
path that returns early:

- The size of the reservation used to live in a member alongside the
  pointer, and the path that gives up on a stream too long to ever form
  a message returned without setting it. The caller's next EndWrite()
  then failed its CHECK, so a peer could abort the process by sending
  128MB of varint continuation bytes. The count now lives in the handle,
  where it cannot fall out of step with the pointer it describes.
- traceconv dropped the reservation it sniffs the first chunk in
  whenever the trace turned out to be compressed, and again whenever the
  decompressor errored.
- RemoteTraceProcessor dropped one whenever a recv failed.

unixd additionally re-serialized each tokenized message back into its
TraceProcessorRpcStream framing and pushed it through a second ring
buffer inside Rpc. Rpc::OnRpcMessage() dispatches it as-is.

  out/linux_clang_release/perfetto_benchmarks \
      --benchmark_filter='ProtoRingBufferIngest|ProtoRingBufferDispatch'
  ingest, 4KB reads    142 ns -> 98.3 ns
  ingest, 1MB reads   38.4 us -> 19.2 us
  dispatch             171 ns -> 99.1 ns

traceconv also drops a 64MB read buffer: peak RSS 62.7MB -> 13.6MB.