[1/2] x/cli/output: Add an abstraction to take care of output rendering

[AlexisMontagne]

What does this PR do?

A demo is worth 1000 words:

Imagine:

type subValue struct {
	Text string `flag:"text,t"`
}
type config struct {
	Values map[string]subValue `flag:"values,v"`
}

type result struct {
	Message string `json:"message" yaml:"message"`
	Foo     string `json:"foo"     yaml:"foo"`
	Bar     string `json:"bar"     yaml:"bar"`

	SubValue  subValue
	SubStruct map[string]subValue
}

func main() {
	staticCmd := output.DefaultStaticCommand(
		func(_ context.Context, _ cli.CommandContext, cfg config) ([]result, error) {
			return []result{
				{
					Message: "success",
					Foo:     cfg.Values["foo"].Text,
					Bar:     cfg.Values["bar"].Text,
					SubStruct: map[string]subValue{
						"zzz": {Text: "zzz"},
					},
				},
			}, nil
		},
		output.WithShortHelp[config, []result]("example command"),
	)

	cli.NewApp(
		cli.WithName("example"),
		cli.WithCommand(
			output.WrapDefaultCommand(
				staticCmd,
				table.NewDefaultTablePrinter[result](),
				table.NewDefaultCSVPrinter[result](),
			),
		),
	).Run(context.Background())
}

you can now have multi rendering codec program that are "unix philosophy ready".

$ go run ./example
- message: success
  foo: ""
  bar: ""
  subvalue:
    text: ""
  substruct:
    zzz:
        text: zzz

$ go run ./example -o json
[{"message":"success","foo":"","bar":"","SubValue":{"Text":""},"SubStruct":{"zzz":{"Text":"zzz"}}}]

$ go run ./example -o table
Message  Foo  Bar  SubValue.Text  SubStruct
success                           map[zzz:{zzz}]

$ go run ./example -o csv
Message,Foo,Bar,SubValue.Text,SubStruct
success,,,,map[zzz:{zzz}]

What are the observable changes?

Good PR checklist

• Title makes sense
• Is against the correct branch
• Only addresses one issue
• Properly assigned
• Added/updated tests
• Added/updated documentation
• Properly labeled

Additional Notes

[xgoffin]

Honestly I understand nothing of any of this. I understand its purpose but how it gets there from a code standpoint? Nope.
I don't think it's worth changing code over this, but this desperately needs a "walkthrough" doc that says which bit is responsible for what. Also means I can't exactly review this.

[xgoffin]

I'll be 100% straight here: I have no idea what this means.
How about adding a little example to the comment? 🤔

[AlexisMontagne]

checkout ./configurator_test.go it explicit the behavour quite extensively

[xgoffin]

We have several nolint:wrapcheck in the coming files: do they serve any purpose in asserting errors? Why put them and not simply a wrap?

[xgoffin]

Given that this is mostly printing, we can consider panicking if the Walk failed, but it is not a hill I will die on

[xgoffin]

package output_test? 🤔 package output at the same level though. Either rename or add a layer?

[AlexisMontagne]

as this file implements some "integration" test i wanted to keep things separated to make sure there is no interference of same package private structs. As the whole shebang relies on quite a bit of reflection