all: understand binary size changes vs 1.14

I was curious about binary size changes from 1.14 to tip. The results:

file      before    after     Δ        %        
addr2line 4307728   4415680   +107952  +2.506%  
api       5972696   5256224   -716472  -11.996% 
asm       5134472   5098312   -36160   -0.704%  
buildid   2843720   2901096   +57376   +2.018%  
cgo       4823736   4843608   +19872   +0.412%  
compile   24899576  19983664  -4915912 -19.743% 
cover     5259800   5292392   +32592   +0.620%  
dist      3665080   3718888   +53808   +1.468%  
doc       4672712   4071904   -600808  -12.858% 
fix       3372856   3422024   +49168   +1.458%  
link      6613720   6755112   +141392  +2.138%  
nm        4253280   4373520   +120240  +2.827%  
objdump   4655376   4763232   +107856  +2.317%  
pack      2294280   2364760   +70480   +3.072%  
pprof     14747604  14618708  -128896  -0.874%  
test2json 2819320   2889496   +70176   +2.489%  
trace     11669292  11783892  +114600  +0.982%  
vet       8342376   7231080   -1111296 -13.321% 
total     120347624 113783592 -6564032 -5.454%  

This immediately raises a few questions.

• Why are a few tools significant smaller? (cmd/compile shrank mostly because of the rulegen changes at the beginning of the cycle. I don't understand cmd/doc, cmd/vet, and cmd/api.)
• Why are most tools a bit larger? Did a core package (like runtime) grow considerably? Was it due to compiler regressions? Something about the new linker?

There may not be any bugs here, but it'd be nice to understand a bit better what happened.

Anybody up for doing some sleuthing?

Of note for anyone investigating, you'll discover that object files are ~50% bigger at tip than 1.14. This is due to the -newobj flag being enabled by default. If you're going to use object files to investigate, you probably want to disable it.