cmd/compile: compile all functions concurrently

CL 40693 added concurrent backend compilation support,
and used it for user-provided functions.
Autogenerated functions were still compiled serially.
This CL brings them into the fold.
As of this CL, when requested,
no functions are compiled serially.

There generally aren't many autogenerated functions.
When there are, this CL can help a lot,
because autogenerated functions are usually short.
Many short functions is the best case scenario
for concurrent compilation; see CL 41192.

One example of such a package comes from Dave Cheney's benchjuju:
github.com/juju/govmomi/vim25/types.
It has thousands of autogenerated functions.
This CL improves performance on the entire benchmark
by around a second on my machine at c=8, or about ~5%.

Updates golang#15756

Change-Id: Ia21e302b2469a9ed743df02244ec7ebde55b32f3

Author: josharian

src/cmd/compile/internal/gc/main.go

@@ -579,13 +579,6 @@ func Main(archInit func(*Arch)) {
 
 		compileFunctions()
 
-		// We autogenerate and compile some small functions
-		// such as method wrappers and equality/hash routines
-		// while exporting code.
-		// Disable concurrent compilation from here on,
-		// at least until this convoluted structure has been unwound.
-		nBackendWorkers = 1
-
 		if compiling_runtime {
 			checknowritebarrierrec()
 		}

src/cmd/compile/internal/gc/obj.go

@@ -143,6 +143,17 @@ func dumpobj1(outfile string, mode int) {
 	dumpimportstrings()
 	dumpbasictypes()
 
+	// The first call to dumpsignats can generate functions,
+	// like method wrappers and hash and equality routines.
+	compileFunctions()
+
+	// Process any new signats added during compilation.
+	// No need to loop here; signats from compiling the generated
+	// functions should not themselves generate new functions.
+	// If they do, we'll know about it; the sanity check of
+	// len(compilequeue) in gc.Main will fail.
+	dumpsignats()
+
 	// Dump extra globals.
 	tmp := externdcl