Added ability to include directories as an extension of the config file

[PolpOnline]

Standards checklist:

• The PR title is descriptive.
• The code compiles (cargo build)
• The code passes rustfmt (cargo fmt)
• The code passes clippy (cargo clippy)
• The code passes tests (cargo test)
• Optional: I have tested the code myself
  • I also tested that Topgrade skips the step where needed

I have tested it by myself, but I am not sure if I set all the merge behaviours correctly.
@openjck you may want to test this.

closes #405

[Dreaming-Codes]

Overall, this is a generally good PR, but I would recommend a few minor improvements.

[PolpOnline]

Blocking this from getting merged because the commands, pre_commands and post_commands fields don't have a merge strategy yet, will surely implement it later.

[openjck]

Thanks for your interest in this issue.

This part caught my attention. If consistency with other tools is important, it might be good to look at how other tools handle this. It's my understanding that Git, Vim, Bash, and others don't have the main configuration file take precedence. Instead, settings at the bottom of those configuration files take precedence over settings at the tops of those files, and included files are treated as though their contents are inlined.

For example, with the following setup, the effective email address would be included@example.com:

// .gitconfig
[user]
  email = main@example.com

[include]
  path = .gitconfig.included

// .gitconfig.included
[user]
  email = included@example.com

However, if the include is moved up, the effective email address would be main@example.com:

// .gitconfig
[include]
  path = .gitconfig.included

[user]
  email = main@example.com

// .gitconfig.included
[user]
  email = included@example.com

As far as I know, the same principle is true for Bash, Vim, and others. Settings at the bottom override settings at the top, and included files are treated as if their contents exist at the location of the include.

[PolpOnline]

This can't be done, not without a breaking change in the way the misc config entries are handled.
This is because as of now these entries are handled in the global scope, and adding an [include] section in between these breaks the following ones, because there is currently no way to specify a return to global scope in TOML files.

The simplest way to fix this is to add a section named [misc] and move all the currently-in-global-scope entries to it.
The problem with this approach is that it breaks all the previously-created config files.

[PolpOnline]

@DottoDev since you are the maintainer of this repository, I'm asking you to tell me how to proceed.

If we are going to migrate all currently-in-global-scope entries to the new [misc] section, I'm available to adapt topgrade to auto migrate the config file.

[s34m]

If config files can be auto migrated it would be a good idea.

[PolpOnline]

I've just pushed a commit to resolve this. I've already tested it myself, but you might want to check it out too @openjck.

[s34m]

lgtm

[s34m]

Cargo fmt and clippy checks need to passbefore a merge can occure.

[s34m]

Thanks for the work