Upgrade rpc and tally, remove x86 emulation on arm

[Groxx]

With the original goal of "upgrade protoc so we don't need rosetta2 on arm macs", covered by #6557, this is essentially just "upgrade protoc and anything else that needs to change".

I arbitrarily picked latest for it, buf, and protoc-gen-yarpc-go, which triggered a chain of other upgrades:

• protoc 3.14.0 -> 29.2
• buf 0.36.0 -> 1.48.0
• yarpc (as it hosts protoc-gen-yarpc-go) v1.70.3 -> v1.75.3
• thriftrw v1.29.2 -> v1.32.0
• tally v3.3.15 -> v3.5.8
• prometheus metrics emitter v0.8.1 -> v1.12.8
  • I believe this is needed due to yarpc upgrade -> tally upgrade -> no longer compatible.
• tchannel v1.22.2 -> v1.34.4
• a bunch of other mostly-minor-looking transitive upgrades as a consequence of the above changes

And, aside from uber-go/tally#142 fixing a histogram-test-scope-snapshot bug that I was relying on (it cleared data on each call, now it leaves it like other metrics types), that's it. Surprisingly.

I intend to go through all of these more carefully to see what has changed, but for codegen purposes (e.g. protoc itself) the full set of changes amount to just generated comments using correct sample-code indentation:

//	if err != nil {
//	  return err         // before
//		return err   // after
//	}

which is absolutely trivial.
Probably because gogo is deprecated and has not changed, and it's responsible for most of our codegen.

---

If we don't want to do the rest of these upgrades, I can just upgrade protoc and buf - that runs with our older plugins and makes no output changes at all, so only the makefile changes here are actually needed to fix the original goal of "no more x86 emulation".

I'm a little inclined to try to upgrade the rest of our rpc stack though, as it's evidently a bit out of date. Since codegen didn't really change, it'd mostly be metrics as possibly-questionable, as yarpc and many of the other base libraries have been very stable and probably safe by default.

The main other upgrade/change that we should probably consider is gogo, because it has been deprecated for 2.5 years now.
I'm not sure OTOH what this would be changed to though, nor if it's compatible... which is just yet another reason to not let these types leak into your code internals. Stuff deprecates and migrates.