Add config management commands (show, edit, set)

[kichristensen]

What does this change

Adds three new commands for managing Porter's configuration file:

• porter config show [--output FORMAT] - Display current config
• porter config edit - Edit config in $EDITOR
• porter config set KEY VALUE - Set individual config values

Examples

Show config (displays defaults if no config exists):

$ porter config show
allow-docker-host-access = false
build-driver = "buildkit"
verbosity = "info"
...

$ porter config show -o json
{
  "build-driver": "buildkit",
  "runtime-driver": "docker",
  ...
}

Set individual values:

$ porter config set verbosity debug
Config saved to /home/user/.porter/config.toml
Set verbosity = debug

$ porter config set logs.level info
Config saved to /home/user/.porter/config.toml
Set logs.level = info

Edit in your preferred editor:

$ porter config edit
# Opens config.toml in $EDITOR

Features

• Multi-format support: toml (default), yaml, json
• Format preservation: modifications preserve existing file format
• Format conversion: show -o converts between formats
• Type-safe value setting with automatic conversion (string, bool, int, nested fields)
• Domain validation with helpful error messages
• Creates default config if none exists

What issue does it fix

Closes #1077

Notes for the reviewer

Key design decisions:

• Reflection-based field discovery (no manual field mappings)
• Tag-based validation using validate:"oneof=..." struct tags
• Format detection from file extension
• Preserves existing format for set/edit, allows conversion with show

Checklist

• Did you write tests?
• Did you write documentation? (help text with examples)
• Did you change porter.yaml or a storage document record? Update the corresponding schema file.
• If this is your first pull request, please add your name to the bottom of our Contributors list. Thank you for making Porter better! 🙇‍♀️

[dgannon991]

Additional tests AI recommend adding;

• Attempt to set a non-primitive field (slice/map/struct) and assert a descriptive error.
• Attempt to set an exported field whose underlying type is a named numeric/enum to ensure SetString/SetInt works for named types.
• Tests that simulate FileSystem failures for SaveConfig and CreateDefaultConfig.
• An integration-style test for porter.SetConfig path that exercises loading existing file + saving changes (you already have this partly, but exercise the CLI path end-to-end).
• Test case-insensitive inputs if you decide to normalize values (or add docs that values are exact).

[dgannon991]

Does this mean if we miss an annotation in a config file, it won't work here? (E.G. I provide TOML + YAML, but the user requests JSON)

[kichristensen]

If for example we something like this, where the JSON annotation is missing:

type Data struct {
  BuilDriver string `toml:"build-driver" yaml:"build-driver"
}

This function will find anyway because it loops through all of them, the requested format is not considered here. It currently works because I assume that the value will be same across all formats.
The annotation is used during marshaling to the requested format, meaning it must there for each supported configuration format.
For this specific function it will only "fail" if the field annotation differs between formats, which is a little confusing.
All input is appreciated, I'm not 100% sure what I think myself.

[dgannon991]

Ah OK, that makes a lot more sense. Is there any form of validation we could add for the values being the same across the different format types?

[kichristensen]

Additional tests AI recommend adding;

* Attempt to set a non-primitive field (slice/map/struct) and assert a descriptive error.

* Attempt to set an exported field whose underlying type is a named numeric/enum to ensure SetString/SetInt works for named types.

* Tests that simulate FileSystem failures for SaveConfig and CreateDefaultConfig.

* An integration-style test for porter.SetConfig path that exercises loading existing file + saving changes (you already have this partly, but exercise the CLI path end-to-end).

* Test case-insensitive inputs if you decide to normalize values (or add docs that values are exact).

Added tests for the first two points, they were already handled, but not explicitly tested.
Will look into the remaining 3 bullets