Overhaul the config file structure

[AThePeanut4]

I want to suggest some general feature

The current structure of the config file is rather complicated and unintuitive - see #1193.

I propose a new structure where every step is a new subsection, inspired by starship's config file. Each one would have an enabled key, and those that need more stuff in the config file could have more keys. Custom steps could be [custom.{name}], just like starship. Generic config options (basically those under [misc]) could go in the unnamed section at the top of the file.

This would obviously be a big breaking change, but I think it would make the configuration much easier to understand. As part of this, there could also be a website similar to starship's that explains all the config options, rather than having a config.example.toml listing everything.

[GideonBear]

Ref #683, which are the [custom.{name}] you are talking about.
They can replace [commands] entirely.
They should be able to be used with --only and --disable, which is #392.

[GideonBear]

There should be a config migration tool built into Topgrade that users can use to (while not preserving comments) migrate their config to v17.

[GideonBear]

Ref #515
Ref #1387
Ref #1049 (pay attention to where we want this in the new config file)
Ref #624 ?
Ref #399
Ref #194

[GideonBear]

Let's split up the files to one step(group) per file, make the section names exactly the step id, and move the definition of the config substructs to those step files.

[GideonBear]

Opt-in steps currently have a manual check for [step] enabled = true in the config. These manual checks can be removed, and we can combine that opt-in behavior with disable and only.

[GideonBear]

Ref #748
I said in #515:

I quite like the idea of cleanup = true just meaning [*.cache] enable = true

I also quite like the idea of assume_yes = true just meaning [*] yes = true.

[GideonBear]

Ref #1204, which is either not necessary if we make the config good enough, or should be tackled at the same time

[GideonBear]

We need to think about the relation between a step's "id" (used for --only and config) and a step's "key" (the pretty name)

[GideonBear]

Let's also rethink and hopefully remove all the Config::some_option methods, and do the cli/config merging and defaults declaratively instead.