Print count of unrecognized bytes in "buf curl"

[jhump]

Currently, buf curl transcodes the response from the binary format to JSON. However, if the response includes any unrecognized fields, they are just discarded since JSON does not emit unrecognized field data.

So this provides a cue to user's that such data might be in the response and getting dropped (which suggests an incomplete or out-of-date schema) by logging the presence of unrecognized bytes when the -v flag is used.

While in here, I noticed that this was allowing unrecognized fields in the JSON request provided to buf curl, which seems wrong since a likely issue with formulating a request will be a typo in a field name, which would just be ignored instead of validated. I was tempted to fix this by simply using protojson directly. I don't really understand the value of protoencoding having to reproduce the same functionality with a different API. But I suspected you would object to that, so I instead addressed a TODO in here.

But it does beg the question in mind: why have these protoencoding wrappers? Why not directly use proto and protojson for serialization?

[bufdev]

These wrappers give us a common way to do (and enforce) additional behavior on top of the main libs, such as json.compact (to get around the non-determinism problem), and if I remember, reparsing for custom options

[jhump]

@bufdev, ack. I forgot about protojson's non-deterministic output 😭.