Add func start support for Go

[harshivcodes]

Implements func start for the Go worker runtime. Builds the user's Go project and launches the Functions host with the Go worker registered under the native runtime identifier

Build & Launch Flow

• src/Cli/func/Helpers/GoHelpers.cs:
  • BuildProject() runs go build -o app[.exe] . and surfaces stderr / non-zero exits as CliException
  • AssertBinaryExists() validates the compiled binary for the --no-build path with an actionable error
• src/Cli/func/Actions/HostActions/StartHostAction.cs: PreRunConditions adds a Go branch — version check, then BuildProject() or AssertBinaryExists() based on --no-build
• src/Cli/func/Helpers/WorkerRuntimeLanguageHelper.cs: maps FUNCTIONS_WORKER_RUNTIME=native → WorkerRuntime.Go so the host's runtime identifier resolves correctly inside
  the CLI

How it works

1. func start resolves runtime via FUNCTIONS_WORKER_RUNTIME=native (written by func init)
2. CLI verifies Go ≥
   1.24, then builds app (or app.exe on Windows)
3. Host loads workers/native/worker.config.json and launches the binary

[liliankasem]

We don't need to handle this in this pr, but as a follow up - I have some thoughts about this native -> language resolution/story.

We should refactor how the CLI handles FUNCTIONS_WORKER_RUNTIME=native. native is the host's identifier for any worker registered with language="native" so it isn't really a worker runtime in the same sense as python or node. It's more of a category.

Options to explore:

1. Sidecar setting in local.settings.json (e.g. FUNCTIONS_WORKER_NATIVE_LANGUAGE=go) written by func init and read by every CLI action that branches on language (when FUNCTIONS_WORKER_RUNTIME is native).

2. Subcommand-style language dispatch for start, similar to how init already uses InitNodeSubcommandAction / InitDotnetSubcommandAction to differentiate languages within a runtime.

3. Marker-file detection as a fallback only (current PR's go.mod check) but driven by an explicit setting first.

The goal being that we keep WorkerRuntimeLanguageHelper a pure mapping (no project sniffing), keep native language-agnostic in the helper, and surface a single source of truth that downstream actions (start, pack, publish) can branch on.

Might be worth a conversation about this. But also we don't need to overinvst here with v5 in the works at the moment.

[liliankasem]

This is fine for now, but before we release the go support preview - we need to have a conversation about go/native support in v5 and make sure the experience in v4 aligns with our future plans to avoid supporting 2 different experiences for native