Feat: Kusion Server apply can use KubeConfig from a secret provider

What would you like to be added?

Kusion Server should be able to add KubeConfig needed for preview, apply and destroy.
Suggestion is to:

• 1. add the ability (API and GUI) to upload a kubeconfig, store the kubeconfig in a specified secret provider (supporting aws, azure, gcp, alicloud and viettel cloud currently), return a secret reference (ref://xxx/xxx/xxx), and later reference the kubeconfig in the workspace config (this is already supported)
     and/or
• 2. support directly retrieving a pre-existing kubeconfig from a supported secret provider.

The difference between the two is the first one doesn't require the user to be familiar with the specific secret provider per se because the secret lifecycle is entirely contained within Kusion. The second one require a step to upload the kubeconfig by the user, which is more complex but provides more flexibility. We can support both too.

Why is this needed?

Kusion determines the KubeConfig used by a preview, apply and destroy operation by reading the KUBECONFIG_PATH or KUBECONFIG_CONTENT. See here for details.
However this requires either the kubeconfig to be stored on the server (when using KUBECONFIG_PATH, or the kubeconfig content to be exposed in the Spec, which is unsafe).
The proper place to store sensitive info like a kubeconfig is the secret provider, which kusion already supports. So adding the ability to process KubeConfigs there is reasonable.

Start by reading pkg/engine/runtime/kubernetes/kubernetes_runtime.go around line 433 to understand the existing KUBECONFIG_PATH and KUBECONFIG_CONTENT handling. Then map the Kusion Server API and GUI entry points and the existing secret-provider integrations. Done should include an agreed approach for uploading or retrieving kubeconfig data, returning a secret reference, and using it for preview, apply, and destroy.