feat: support -ext-str and -ext-code flags for jsonnet std.extVar

[takaishi]

Summary

This PR adds top-level -ext-str and -ext-code flags that bind values to str.extVar() references then the configuration filer is a Jsonnet file. There flags are mirroring the upstream jsonnet CLI. Also fixes the Plugin struct so plugins declared in Jsonnet configs are decoded correctly.

Background

Until now, Jsonnet configurations could only be evaluated with values hard-coded in the file (or imported via libsonnet). There was no way to inject values from the CLI or the environment at evaluation time, which made it awkward to share a single Jsonnet template across environments (e.g. region, cluster name, task counts).

The upstream jsonnet CLI exposes --ext-str / --ext-code for exactly this purpose, and ecschedule users expect the same ergonomics when running ecschedule apply / diff / dump / run.

Separately, the Plugin struct only had yaml tags. When a Jsonnet config went through the Jsonnet → JSON → YAML path, the plugins block decoded into empty Plugin values, so plugins declared in Jsonnet did not work.

Changes

• CLI: Add repeatable -ext-str and -ext-code flags on the top-level command.
  • -ext-str KEY=VALUE binds a string; -ext-code KEY=VALUE binds a Jsonnet expression (numbers, arrays, objects, …).
  • Bare -ext-str KEY / -ext-code KEY reads the value from the environment variable of the same name and errors if it is not defined.
• Library API: Extend LoadConfig with functional options WithExtStr(map[string]string) and WithExtCode(map[string]string). These are
  forwarded to jsonnet.VM.ExtVar / ExtCode when the config file has a .jsonnet extension.
• Plugin decoding: Add json tags to Plugin (name, config, func_prefix) so plugins declared in Jsonnet configs decode correctly.