Add Go language support to func init

[Harshitha Vegaraju (harshivcodes)]

Changes

• func init support for Go: new InitGoSubcommandAction and GoHelpers to scaffold a Go project (including main.go, go.mod, and local.settings.json) behind the Native
  worker runtime.
• Language inference: added TryNormalizeLanguage in WorkerRuntimeLanguageHelper to preserve language inference for existing runtimes while accommodating Go.
• Static resources: bundled a main.go sample template with the Functions Go SDK.
• Tests: unit tests (GoHelperTests, InitActionGoTests) and E2E tests (GoInitTests) covering scaffolding, settings, and language normalization.

[Lilian Kasem (liliankasem)]

A couple of smaller follow-ups on how Go is wired into InitAction — most of the per-runtime branching here matches what Python/Node/etc. already do, so no concern there. Two spots stood out though:

1. FUNCTIONS_WORKER_RUNTIME mapping.

GetRuntimeMoniker(WorkerRuntime.Go) returns "go", but the value we actually need to write into local.settings.json is "native". Right now that mapping lives inline in WriteLocalSettingsJson:

string workerRuntimeSetting = workerRuntime == WorkerRuntime.Go
    ? "native"
    : WorkerRuntimeLanguageHelper.GetRuntimeMoniker(workerRuntime);

Could we move that into WorkerRuntimeLanguageHelper (e.g. a GetFunctionsWorkerRuntimeSetting(workerRuntime) helper)? Every other runtime round-trips between the moniker and the host-facing setting, so anyone else who needs the host value will reach for GetRuntimeMoniker and silently get the wrong string. Centralizing it keeps the divergence in one place.

2. Dispatch in InitFunctionAppProject.

Every other runtime flows through InitLanguageSpecificArtifacts (which has its own internal switch). Go is the first to be handled with a sibling branch at the call site:

if (ResolvedWorkerRuntime == WorkerRuntime.Go)
{
    await GoHelpers.SetupProject(...);
}
else
{
    await InitLanguageSpecificArtifacts(...);
}

Could we add a case WorkerRuntime.Go: inside InitLanguageSpecificArtifacts that calls GoHelpers.SetupProject instead? Keeps the dispatch in one place and matches the existing shape. Small thing but it's the difference between "Go fits the pattern" and "Go is the exception that splits dispatch in two."

[Aishwarya Bhandari (aishwaryabh)]

I don't see this test running in the pipeline. You would need to add the following to all of the test-e2e-*.yml

  - name: Go
    languageWorker: 'Go'

[Aishwarya Bhandari (aishwaryabh)]

approving to unblock PR. Pipeline changes should be addressed in a future PR