earthly config key "" panics

[alexcb]

running:

earthly config global.conversion_parallelism ''
panic: runtime error: index out of range [0] with length 0

fails with panic.

It's also not obvious how config options can be deleted.

[alexcb]

To expand on this:

If my config is initially:

$ cat ~/.earthly/config.yml
global:
    buildkit_additional_args:
        - '-e'
        - 'BUILDKIT_SCHEDULER_DEBUG=1'

Then i call earthly config global.conversion_parallelism 5, it turns into:

$ cat ~/.earthly/config.yml
global:
    buildkit_additional_args:
        - '-e'
        - 'BUILDKIT_SCHEDULER_DEBUG=1'
    conversion_parallelism: 5

How can I delete it? Let's try running: earthly config global.conversion_parallelism ""

that produces:

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/earthly/earthly/config.valueToYaml({0x7ffe6611dbc5, 0x0})
	/earthly/config/config.go:266 +0x125
github.com/earthly/earthly/config.UpsertConfig({0xc00039e000, 0x1e, 0x200}, {0x7ffe6611dba7, 0x1d}, {0x7ffe6611dbc5, 0xf23440})
	/earthly/config/config.go:180 +0x3bb
main.(*earthlyApp).actionConfig(0xc0000d7200, 0xc000110300)
	/earthly/cmd/earthly/main.go:2576 +0x1e5
github.com/urfave/cli/v2.(*Command).Run(0xc00014f320, 0xc00003cf40)
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/command.go:163 +0x64a
github.com/urfave/cli/v2.(*App).RunContext(0xc000583040, {0x11f77a8, 0xc0002e0a80}, {0xc000110040, 0x4, 0x4})
	/go/pkg/mod/github.com/urfave/cli/v2@v2.3.0/app.go:313 +0x81e
main.(*earthlyApp).run(0xc0000d7200, {0x11f77a8, 0xc0002e0a80}, {0xc000110040, 0x4, 0x4})
	/earthly/cmd/earthly/main.go:1513 +0xad
main.main()
	/earthly/cmd/earthly/main.go:253 +0x538

I would have expected the above to cleanly detect the error such as what happens when you pass it a non-int:

$ earthly config global.conversion_parallelism not-an-int
Error: upsert config: cannot set global.conversion_parallelism to not-an-int, as the types are incompatible

This still doesn't address how do we delete this option? In addition to fixing the above error-handling, I think we need a --delete flag.