`glooctl check` panics when client version differs from server

[jameshbarton]

Describe the bug glooctl check panics in some cases when client version differs from server.

To Reproduce

1. Install glooctl v1.6.26
2. Install Gloo Edge Enterprise 1.8.0
3. Run glooctl check
4. Observe the panic.

% glooctl check
----------
glooctl binary version (1.6.26) differs from server components (v1.8.0) by at least a minor version.
Consider running:
glooctl upgrade --release=v1.8.0
----------

Checking deployments... 3 Errors!
Checking pods... 6 Errors!
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x3caf199]

goroutine 1 [running]:
github.com/solo-io/gloo/projects/gloo/cli/pkg/cmd/check.getNamespaces(0x4d6ed00, 0xc000128008, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	/workspace/gloo/projects/gloo/cli/pkg/cmd/check/root.go:301 +0x59
github.com/solo-io/gloo/projects/gloo/cli/pkg/cmd/check.CheckResources(0xc000fe2000, 0x0, 0x0)
	/workspace/gloo/projects/gloo/cli/pkg/cmd/check/root.go:97 +0x632
github.com/solo-io/gloo/projects/gloo/cli/pkg/cmd/check.RootCmd.func1(0xc000315340, 0x697d9a0, 0x0, 0x0, 0x0, 0x0)
	/workspace/gloo/projects/gloo/cli/pkg/cmd/check/root.go:52 +0x43
github.com/spf13/cobra.(*Command).execute(0xc000315340, 0x697d9a0, 0x0, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:850 +0xb21
github.com/spf13/cobra.(*Command).ExecuteC(0xc0005bab00, 0xc000315340, 0x0, 0x0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:958 +0x70f
github.com/spf13/cobra.(*Command).Execute(0xc0005bab00, 0x0, 0x0)
	/go/pkg/mod/github.com/spf13/[email protected]/command.go:895 +0x3b
main.main()
	/workspace/gloo/projects/gloo/cli/cmd/main.go:11 +0x34

Expected behavior glooctl check fails gracefully even if it cannot complete the operation due to the version discrepancy.

Workaround Workaround is to upgrade glooctl to same version as server.

Additional context

• glooctl version 1.6.26
• Gloo Edge version 1.8.0
• May be same issue as #5049 but not enough context to know for sure