x/build: gccgo builder for testing $GOROOT/test directory

[mdempsky]

The $GOROOT/test directory contains test files that are also tested by gccgo, but that we don't regularly test against gccgo. That means:

1. @ianlancetaylor has to periodically spend a bunch of time updating tests for gccgo. E.g., these CLs span about 3 weeks from late Nov 2020 to mid Dec 2020: b94346e, d6abf29, a45e12f, 848dff6, 73e796c, 58768ae, bacb307, 6d2b335, ce61ccc, be10af7, 5a25a3f, 685a322, 731bb54,

2. When updating existing tests, folks are scared to ever remove pattern alternatives from existing regexps for fear of breaking gccgo. For example, test/fixedbugs/issue11326.go has tests with 5 alternatives, even though we've only ever supported 3 type checkers (gc, gccgo, and go/types):

   go/test/fixedbugs/issue11326.go

   Lines 21 to 25 in 1ed0d12

   	var _ = 1e646456992 // ERROR "1e\+646456992 overflows float64|floating-point constant overflow|exponent too large|overflows float64|overflows"
   	var _ = 1e64645699 // ERROR "1e\+64645699 overflows float64|floating-point constant overflow|exponent too large|overflows float64|overflows"
   	var _ = 1e6464569 // ERROR "1e\+6464569 overflows float64|floating-point constant overflow|exponent too large|overflows float64|overflows"
   	var _ = 1e646456 // ERROR "1e\+646456 overflows float64|floating-point constant overflow|exponent too large|overflows float64|overflows"
   	var _ = 1e64645 // ERROR "1e\+64645 overflows float64|floating-point constant overflow|exponent too large|overflows float64|overflows"

   Additionally, the 5th alternative "overflows" is a substring of alternatives 1 and 4, so they needn't be included anymore.

I think both of these issues would be helped if we had a builder (and slowbot) that ran the $GOROOT/test tests in gccgo mode.

/cc @ianlancetaylor @golang/release

[ianlancetaylor]

I would support this but I'll note that many tests still do not pass with gccgo. I ran out of my self-determined time to work on updating the testsuite.

[mdempsky]

@ianlancetaylor Ack, I noticed that while re-triaging the types2 expected-failures list last night. (E.g., several of fixedbugs/issue7525*.go still ICE with gccgo.)

I'd be supportive of extending the types2 expected-failures mechanism to allow gccgo expected-failures and just checking in what we currently have as a baseline. That way we at least halt further backsliding.