Add --enable-nested-virtualization to setup-gcp - #1669

`setup-gcp` creates one node pool, `substrate-node-pool`, and sets no
`SandboxConfig` on it, so nothing about that pool is gVisor-specific. The
`gvisor-pool` named by `NODE_POOL_NAME` is a different pool that only
`hack/teardown.sh` touches, so the old variable named a pool this tool never
creates. Micro-VM workers need the same knob for a non-gVisor runtime, which
makes the name actively misleading.

The `--machine-type` flag and the `Config.MachineType` field already carried
neutral names, so only the environment variable and its help text change.

Developers copy `hack/ate-dev-env.sh.example` to an untracked `.ate-dev-env.sh`
once and edit it from there, so most existing setups still export the old name.
`setup-gcp` reads it when `NODE_MACHINE_TYPE` is unset and warns, which keeps
those setups on their chosen machine type instead of dropping them onto the
`c3-standard-4` default without a word. Remove the fallback once the team has
renamed the variable.

Verified with `go build ./tools/...` and `go test ./tools/setup-gcp/...`,
covering the new name, the old name, both set, and neither.

Micro-VM workers (`ateom-microvm`) need `/dev/kvm`, which a GKE node only has
when its pool was created with nested virtualization. `setup-gcp` had no way to
ask for it, so provisioning a cluster for micro-VM work meant building the node
pool by hand with `gcloud`.

`create cluster` and `bootstrap` now accept `--enable-nested-virtualization`
(`ENABLE_NESTED_VIRTUALIZATION`), which sets
`AdvancedMachineFeatures.EnableNestedVirtualization` on the pool the tool
creates. It defaults to on, since running micro-VM workers is a reason to
create a cluster with this tool and the default `c3-standard-4` supports the
feature. Pass `--enable-nested-virtualization=false` for a cluster that does
not need it; the field then stays unset, leaving GKE its own default. A machine
type GCE excludes from the feature, such as E2 or an AMD type other than N4D,
now fails at cluster creation rather than quietly creating nodes without
`/dev/kvm`.

GKE fixes the setting at node creation and cannot update an existing pool into
it. The reconcile path therefore logs a warning naming the remedy instead of
reporting a change it did not make. With the default on, that warning reaches
every existing cluster whose pools predate the flag, which is the intended
signal: those nodes cannot place micro-VM workers. The check passes when any
pool has the feature, because keeping KVM nodes in a second pool added by hand
is a normal arrangement.

Verified with `go test ./tools/setup-gcp/...`, covering the request builder with
the flag on and off, and the pool scan across nil, empty, mixed, and disabled
clusters.

…un time

getEnv parses values with strconv.ParseBool, which rejects spellings such as
"off" and "no". It discarded those values without a word and fell back to the
default, so ENABLE_NESTED_VIRTUALIZATION=off left nested virtualization on.
Log the variable, its value, and the fallback when parsing fails. Commands
register flags for the same variable in more than one init, so the log records
each variable once rather than once per registration.

resolveMachineTypeDefault treated NODE_MACHINE_TYPE as set whenever it was
present, so exporting it empty suppressed the GVISOR_NODE_MACHINE_TYPE fallback
and left the machine type blank. GKE then picks e2-medium, which cannot run
nested virtualization. Treat an empty value as unset.

The deprecation warning for GVISOR_NODE_MACHINE_TYPE ran from a package-level
variable initializer, so it fired on every invocation, including --help and
subcommands that never read a machine type. Warn from the commands that read
the flag instead, and stay quiet when --machine-type was passed explicitly.