make: always set CGO_ENABLED=0 for platform builds (#1200)
make: always set CGO_ENABLED=0 for platform builds (#1200)

CGO_ENABLED defaults to "1" if a Go build targets the host system, so
that it can use the system's libc and any other libraries.

For cross-builds (when either the target GOOS or GOARCH don't match the
host's), the Go tool can't assume that a C cross-compiler and the
necessary headers are present, so the default is CGO_ENABLED=0.

This can result in binaries published to NPM being inconsistently
static, since the one matching the host's will be the only one to
dynamically link C libraries. For example, on linux/amd64:

	$ make platform-linux platform-windows platform-linux-arm64 platform-darwin platform-freebsd
	[...]
	$ ldd npm/esbuild-*/bin/*
	npm/esbuild-darwin-64/bin/esbuild:
		not a dynamic executable
	npm/esbuild-freebsd-64/bin/esbuild:
		not a dynamic executable
	npm/esbuild-linux-64/bin/esbuild:
		linux-vdso.so.1 (0x00007ffd24570000)
		libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f35a6718000)
		libc.so.6 => /usr/lib/libc.so.6 (0x00007f35a654b000)
		/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f35a6765000)
	npm/esbuild-linux-arm64/bin/esbuild:
		not a dynamic executable
	npm/esbuild-wasm/bin/esbuild:
		not a dynamic executable
	npm/esbuild-windows-32/bin/esbuild:
		not a dynamic executable
	npm/esbuild-windows-64/bin/esbuild:
		not a dynamic executable

With this change, we always force CGO_ENABLED=0, and the resulting
binaries are consistently non-dynamic no matter the host platform.

This change should be safe, as esbuild seems to have zero cgo code, and
the majority of platform builds for NPM were already defaulting to
CGO_ENABLED=0.
evanw/esbuild,evanw/esbuild,evanw/esbuild,evanw/esbuild