Rework `config` subcommand

[tomschr]

Situation

The config subcommand contains two other subcommands:

$ docbuild config -h
Usage: docbuild config [OPTIONS] COMMAND [ARGS]...

  CLI interface to shows config files how docbuild sees it.

Options:
  -h, --help  Show this message and exit.

Commands:
  app  CLI interface to show the configuration of the application files.
  env  CLI interface to showsthe configuration of the environment files.

Maybe we shouldn't distinguish between env and app subcommand? Or maybe use a specific option and not a subcommand?

Use Case

In m humble opinion, the config subcommand should be used for:

• validating the config and showing validation errors
• showing the config. Especially when the env config contains placeholders the resolved paths are a great tool to debug if everything was correct.
• Something else?

Possible Implementation

Maybe we should move from the distinction between app/env to a more use case oriented subcommand?

For example, we could implement:

• config validate
  We would need to answer where do we want to pass the config file(s). At the moment, for the ENV config we have the options --env-config/--app-config. But passing that, triggers the validation already. If you have a wrong config and want to show the help, the help output won't be shown as validation errors are.

• config show|list
  This prints the complete configuration as JSON. All JSON should go to stdout to make it possible to pass it to other tools (e.g. jq).
  Maybe config list is nice as there is already a git config list command.
  Additionally, we could think about "flattening" the config like git config list does. That would require an option --flat or similar.