Currently, when the compiler emits a symbol name in the object
file, it uses "". for the package path of the package being
compiled. This is then expanded in the linker to the actual
package path.

With CL 173938, it does not need an allocation if the symbol name
does not need expansion. In many cases, the compiler actually
knows the package path (through the -p flag), so we could just
write it out in compile time, without fixing it up in the linker.
This reduces allocations in the linker.

In case that the package path is not known (compiler's -p flag is
missing, or the object file is generated by the assembler), the
linker still does the expansion.

This reduces ~100MB allocations (~10% inuse_space) in linking
k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64.

Also makes the linker a little faster: linking cmd/go on
Linux/AMD64:
Real  1.13 ± 1%  1.11 ± 1%  -2.13%  (p=0.000 n=10+10)
User  1.17 ± 3%  1.14 ± 5%  -3.14%  (p=0.003 n=10+10)
Sys   0.34 ±15%  0.34 ±15%    ~     (p=0.986 n=10+10)

The caveat is that the object files get slightly bigger. On
Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa
(which has a longer import path) gets 2.8% bigger.

This reveals that when building an unnamed plugin (e.g.
go build -buildmode=plugin x.go), the go command passes different
package paths to the compiler and to the linker. Before this CL
there seems nothing obviously broken, but given that the compiler
already emits the package's import path in various places (e.g.
debug info), I guess it is possible that this leads to some
unexpected behavior. Now that the compiler writes the package
path in more places, this disagreement actually leads to
unresolved symbols. Adjust the go command to use the same package
path for both compiling and linking.

Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/174657Reviewed-by: Austin Clements <austin@google.com>