Improve binary size generated code

[jlucaso1]

Hi, @iainmcgin. I was testing running a project on an ESP32 with 4 MB of flash, but buffa ends up contributing to a large binary size.

Here are the results of the experiments: jlucaso1#1 (I prioritized not compromising performance).
Also, check out the comments on the PR: oxidezap/whatsapp-rust#1424 (it includes automated benchmarks and binary size measurements).

What do you think about bringing some of these changes to upstream buffa?

[iainmcgin]

Sorry, it's been a very busy few weeks - taking a look at this now

[iainmcgin]

I ran some benchmarks on a bare-metal node with your code changes. The writer outlining is 8-35% slower across the protobuf types we currently test (google_message1_proto3/encode: +35%, api_response/encode: +21%, analytics_event/encode: +12%, log_record/encode: +10%, mesh/encode: +8%). This seems mostly attributable to call overheads.

With the writer outlining removed, the decode speeds are mostly faster (7-14%).

The parts I'd like to take (with numbers from x64 binaries of your whatsapp.proto):

1. as_option() in the encoders: −93 KB (−6.7%) at z.
2. One-byte varint decode fast path: −62 KB at opt-level=3 and faster decode.
3. Fused singular-field readers: −106 KB owned, −226 KB views at z, neutral at opt-level=3.
4. Erased decode loops with the tiny-message and top-level carve-outs, plus the view single-slot arms: −120 KB owned and −232 KB views at z. The carve-outs are required, since erasure alone makes mesh/decode 49% slower. This is a breaking change, but fine for 0.10.0.

[iainmcgin]

#463