Use up in exec if in PATH

[RedbackThomson]

Description of your changes

Fixes #490

The current logic for setting path to up in the Kubeconfig AuthInfo exec switches depending on the target release version. If we are on the release build, then use "up". If we are on the debug build, then use the current executable path. This has unfortunate side effects when customers use up but don't have the CLI in PATH - the AuthInfo won't ever be able to resolve the exec.

This change standardises the mechanism regardless of release target. The AuthInfo will always fall back to the full path of the up executable, unless we can guarantee we're running it from PATH.

I have:

• Read and followed Upbound's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested

Running from PATH:

$ up ctx acmeco/upbound-gcp-us-west-1/default --profile production -f -
...
users:
- name: upbound
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - organization
      - token
      command: up
...

Running from pwd:

$ ./up ctx upbound/upbound-gcp-us-west-1/nicks-group -f -
...
users:
- name: upbound
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - organization
      - token
      command: /Users/nicholasthomson/Workspace/up/_output/bin/darwin_arm64/up
...

[cbuto]

this worked for me!

small, non-blocking comment

[cbuto]

what if path != cmd? do we need this check or should we always use whats returned by os.Executable()?

[RedbackThomson]

os.Exectuable will always return the full absolute path to up. I think it's cleaner for it to just use up and rely on the PATH instead of hard coding it. That's how other CLIs do it, and I feel it's a good model.

[cbuto]

sounds good to me