This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:

// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''

The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:

	go install -a ./...
	go build -tags netgo -a myprog

Both of these commands now do the right thing without needing -a.

The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.

See the comment for more justification and history.

Summary of recent CLs (to link bugs to this one):

Fixes #3036. Now 'go install ./...' works.
Fixes #6534. Now 'go install ./...' works.
Fixes #8290. Now 'go install ./...' works.
Fixes #9369. Now 'go build -tags netgo myprog' works.
Fixes #10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
  (Each time you switch, everything needed gets rebuilt.
  Switching from Go 1.4 to Go 1.5 will rebuild properly.
  Switching from Go 1.5 back to Go 1.4 still needs -a when
  invoking the Go 1.4 go command.)

Change-Id: I19f9eb5286efaa50de7c8326602e94604ab572eb
Reviewed-on: https://go-review.googlesource.com/10761
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.

The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.

During development work, however, you do want install -a
to rebuild everything, because anything might have changed.

Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.

This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.

Fixes golang#8290.

LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045

Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.

The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.

During development work, however, you do want install -a
to rebuild everything, because anything might have changed.

Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.

This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.

Fixes golang#8290.

LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045

Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.

The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.

During development work, however, you do want install -a
to rebuild everything, because anything might have changed.

Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.

This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.

Fixes golang#8290.

LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045

Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.

The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.

During development work, however, you do want install -a
to rebuild everything, because anything might have changed.

Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.

This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.

Fixes golang#8290.

LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045