Change the way we initialize the kubernetes client to prevent spurious log warnings

[roberthbailey]

Is your feature request related to a problem? Please describe.
A user reported in slack that the sidecar is producing the following log warning after installing via yaml:

{
  "insertId": "mts1lavb2s2in2rp",
  "jsonPayload": {
    "message": "Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.",
    "pid": "1"
  },
  "resource": { ... }
  },
  "timestamp": "2024-01-09T14:41:58.416275082Z",
  "severity": "WARNING",
  "labels": { ... },
  "logName": "...",
  "sourceLocation": {
    "file": "client_config.go",
    "line": "618"
  },
  "receiveTimestamp": "2024-01-09T14:42:01.110633355Z"
}

Describe the solution you'd like
We shouldn't be producing concerning log messages. Since this log is coming from vendored client libraries, it makes me think that we are using the library incorrectly. We should refactor our code so that in the default installation we do not produce this error.

Describe alternatives you've considered
Leave it as-is; maybe add something to the FAQ.

Additional context

• Source of the log message
• Places where we call BuildConfigFromFlags

[markmandel]

As a note, this comes from this PR:
https://github.com/googleforgames/agones/pull/3252/files#diff-1abadecd9f31b440cd957612b5ce5d47eba5b45b9ecc90119b893c6554778a3eL121

Which meant you can expand on local game server hosting within an Agones cluster.

It feels to me like we should do something more along the lines of:

1. Try InClusterConfig() first, if that fails.
2. Then move to try BuildConfigFromFlags instead.

That way, if it's already in the cluster (which is 99% of use cases), it goes to the optimal path, but if not, it can still connect to the external cluster for that workflow (this will require manual testing).