cmd/go: fix TestScript/tool_build_as_needed

This test assumes that changing GOOS/GOARCH results in an
unrunnable binary, but that's not true if the user has
go_GOOS_GOARCH_exec programs in their path (like I do).
This test was timing out waiting to create a gomote to run
a windows/amd64 binary.

Rewrite the test not to assume that alternate GOOS/GOARCH
binaries are unrunnable.

Fixes one failing case in 'go test cmd/go' on my Mac.

Change-Id: Ib5f721f91e10d285820efb5995a3a9bc29833214
Reviewed-on: https://go-review.googlesource.com/c/go/+/718180
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>

Author: rsc

src/cmd/go/testdata/script/tool_build_as_needed.txt

@@ -40,13 +40,15 @@ rm $TOOLDIR/test2json$GOEXE
 go tool -n test2json
 ! stdout $NEWTOOLDIR${/}test2json$GOEXE
 # Set GOOS/GOARCH to different values than host GOOS/GOARCH.
-env GOOS=windows
-[GOOS:windows] env GOOS=linux
-env GOARCH=arm64
-[GOARCH:arm64] env GOARCH=amd64
+env GOOS=js
+env GOARCH=wasm
 # Control case: go run shouldn't work because it respects
 # GOOS/GOARCH, and we can't execute non-native binary.
-! go run cmd/test2json -exec=''
-# But go tool should because it doesn't respect GOOS/GOARCH.
+# Don't actually run the binary because maybe we can.
+# (Maybe the user has a go_js_wasm_exec installed.)
+# Instead just look to see that the right binary got linked.
+go run -n cmd/test2json
+stderr modinfo.*GOARCH=wasm.*GOOS=js
+# go tool should succeed because it doesn't respect GOOS/GOARCH.
 go tool test2json
 stdout '{"Action":"start"}'