See #10164, whenever we introduce a new GOARCH, older Go releases won't
recognize them and this causes trouble for both our users and us (we need to
add unnecessary build tags)

As there aren't many architectures out there, I think we can pre-assign gochar
and goarches to them in Go 1.5 so that when we finally add that architecture
there won't be problems like this. This will also bring the go/build package closer
to the one in the gofrontend project.

The list I have in mind is (sorted alphabetically):

mips{,le}
mips64{,le}
ppc{,le}
s390
s390x
sparc
sparc64

Open questions:

1. although sparc is bi-endian, is there any system that runs it in little-endian mode? We can be future-proof by adding both endians though.
2. what about all those abi variants of mips? should we encode them into the goarch or we add another environment variable GOMIPS=o32/n32/o64/n64? Or we just support the new abi?
3. what if there are new architectures invented in the future?
4. some architectures are only used in embedded systems, should we also add them? (nios2, microblaze, lm32, epiphany, ...) Once we have mips32 port, the first three should be quite straightforward as they all base on mips32.

We should definitely add mips/s390/sparc though, because thare are ports for them in the works.

Pre-assigning gochars probably is less important though.