build: require old Go to build new Go (and convert cmd/dist to Go)

This CL introduces the bootstrap requirement that in order to
build the current release (or development version) of Go, you
need an older Go release (1.4 or newer) already installed.
This requirement is the whole point of this CL.

To enforce the requirement, convert cmd/dist from C to Go.

With this bootstrapping out of the way, we can move on to
replacing other, larger C programs like the Go compiler,
the assemblers, and the linker.

See golang.org/s/go15bootstrap for details.

Change-Id: I53fd08ddacf3df9fae94fe2c986dba427ee4a21d
Reviewed-on: https://go-review.googlesource.com/2470
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

src/cmd/dist/README

@@ -1,45 +1,27 @@
This program, dist, is the bootstrapping tool for the Go distribution.
It takes care of building the C programs (like the Go compiler) and
the initial bootstrap copy of the go tool.  It also serves as a catch-all
to replace odd jobs previously done with shell scripts.

Dist is itself written in very simple C.  All interaction with C libraries,
even standard C libraries, is confined to a single system-specific file
(plan9.c, unix.c, windows.c), to aid portability.  Functionality needed
by other files should be exposed via the portability layer.  Functions
in the portability layer begin with an x prefix when they would otherwise
use the same name as or be confused for an existing function.
For example, xprintf is the portable printf.
As of Go 1.5, dist and other parts of the compiler toolchain are written
in Go, making bootstrapping a little more involved than in the past.
The approach is to build the current release of Go with an earlier one.

By far the most common data types in dist are strings and arrays of
strings.  Instead of using char* and char**, though, dist uses two named
data structures, Buf and Vec, which own all the data they point at.
The Buf operations are functions beginning with b; the Vec operations
are functions beginning with v.  The basic form of any function declaring
Bufs or Vecs on the stack should be
The process to install Go 1.x, for x ≥ 5, is:

	void
	myfunc(void)
	{
		Buf b1, b2;
		Vec v1;
		
		binit(&b1);
		binit(&b2);
		vinit(&v1);
		
		... main code ...
		bprintf(&b1, "hello, world");
		vadd(&v1, bstr(&b1));  // v1 takes a copy of its argument
		bprintf(&b2, "another string");
		vadd(&v1, bstr(&b2));  // v1 now has two strings
		
		bfree(&b1);
		bfree(&b2);
		vfree(&v1);
	}
	
The binit/vinit calls prepare a buffer or vector for use, initializing the 
data structures, and the bfree/vfree calls free any memory they are still
holding onto.  Use of this idiom gives us lexically scoped allocations.
1. Build cmd/dist with Go 1.4.
2. Using dist, build Go 1.x compiler toolchain with Go 1.4.
3. Using dist, rebuild Go 1.x compiler toolchain with itself.
4. Using dist, build Go 1.x cmd/go (as go_bootstrap) with Go 1.x compiler toolchain.
5. Using go_bootstrap, build the remaining Go 1.x standard library and commands.

NOTE: During the transition from the old C-based toolchain to the Go-based one,
step 2 also builds the parts of the toolchain written in C, and step 3 does not
recompile those.

Because of backward compatibility, although the steps above say Go 1.4,
in practice any release ≥ Go 1.4 but < Go 1.x will work as the bootstrap base.

See golang.org/s/go15bootstrap for more details.

Compared to Go 1.4 and earlier, dist will also take over much of what used to
be done by make.bash/make.bat/make.rc and all of what used to be done by
run.bash/run.bat/run.rc, because it is nicer to implement that logic in Go
than in three different scripting languages simultaneously.