Improve kustomize version output

[KnVerey]

• Take advantage of go1.18's BuildInfo, when available, with fallback on the constants set by ldflags we use today. Should fix kustomize version output incomplete when building from source #4617.
• Add json and yaml output formats.
• Deprecate the Go struct output that is currently the default, to be replaced with a simple semver string. kubectl is doing the same: Start deprecating long/golang version information kubernetes/kubernetes#108987
• Change the short output from a Go struct with whitespace errors to a simple semver string, to match kubectl.
• Add more of the build info kubectl version offers, when available from BuildInfo: goVersion, gitTreeState

🚨 TODO: verify that the information will really be correct on a tagged commit, and in the goreleaser context. Most of the information isn't populated in tests: golang/go#33976. Everything looks good on make kustomize (which does go install), but the version is (devel) so not good confirmation.

Local build before

> kustomize version
{Version:unknown GitCommit:$Format:%H$ BuildDate:1970-01-01T00:00:00Z GoOs:darwin GoArch:arm64}

> kustomize version --short
{unknown  1970-01-01T00:00:00Z  }

Local build after

> kustomize version
{Version:(devel) GitCommit:2a0d821bdba197bf70c3883f79b9fad049e84854 GitTreeState:clean BuildDate:2022-05-09T23:45:42Z GoOs:darwin GoArch:arm64 GoVersion:go1.18.1}

> kustomize version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
(devel)

> kustomize version -o yaml
version: (devel)
gitCommit: 2a0d821bdba197bf70c3883f79b9fad049e84854
gitTreeState: clean
buildDate: "2022-05-09T23:45:42Z"
goOs: darwin
goArch: arm64
goVersion: go1.18.1

> kustomize version -o json
{
  "version": "(devel)",
  "gitCommit": "67e0a9a2c602a940247cdde08f77b7fb1d5cf8a5",
  "gitTreeState": "clean",
  "buildDate": "2022-05-09T23:57:55Z",
  "goOs": "darwin",
  "goArch": "arm64",
  "goVersion": "go1.18.1"
}

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: KnVerey

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [KnVerey]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[KnVerey]

/hold on verifying release behaviour will be correct

[k8s-ci-robot]

@KnVerey: This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[KnVerey]

We never had this before and it wasn't working properly in the release, so 🔥 for now

[KnVerey]

🔥 this change as well. The build date used by kubectl really is the build date, not the commit date. I think it comes from here, ultimately: https://github.com/kubernetes/kubernetes/blob/f33ddd1b9c1f53ca9bb7dd8a55c7e15ced1292a8/hack/lib/version.sh#L168

[KnVerey]

We at least do need to keep the date flag. Based on the notes I left on this PR, it seems possible the others always work from the BuildInfo source, in which case we can keep them deleted (but we need to confirm). Perhaps we can add any that we're keeping to the Makefile so that local builds are more sane anyway.

[KnVerey]

Closing in favour of #5000