Move `nix {show-config,doctor}` under subcommands

[roberth]

Is your feature request related to a problem? Please describe.

Keeping the number of top level commands low helps with discoverability.
2/3 suggestions also make the CLI more noun-verb

Describe the solution you'd like

Move

• nix show-config -> nix config show
• nix doctor -> nix config check
• nix describe-stores -> nix config show-store-types (as permitted by the insight that build configuration is also configuration)
• nix describe-stores -> nix help stores
  • render it for the terminal?
  • make it internal?

nix doctor should remain as a hidden alias, it being a stable command.

Describe alternatives you've considered

Status quo; 30 top level commands instead of 28

Additional context

Docker has 58 top level commands, which is definitely too much from what I remember when learning (and probably fewer commands back then). Some may be aliases, but that's not clear during bash completion.

Priorities

Add 👍 to issues you find important.

[edolstra]

Sounds good to me. But arguably nix config show-store-types isn't really config-related, but docs-related. Maybe it should be under nix help, i.e. nix help stores. There are a couple of similar things that could go under nix help, like nix help builtins, nix help fetchers, ...

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-02-17-nix-team-meeting-minutes-33/25624/1

[fricklerhandwerk]

Discussed in the Nix team meeting:

• @thufschmitt: describe stores was my fault, should not be a user-facing command and its output only appear in the manual
  • the information is very important, a big thing that's not documented at all; probably the biggest one
• @fricklerhandwerk: there currently is no nix config command, so we won't gain much yet.
  • @thufschmitt: we could have a subcommand to manipulate configuration eventually
• agreement:
  • hide nix describe stores, follow up on displaying the information in manual and help pages
  • break down actionable tasks for designing a potential nix config; determine our notion of configuration
• @Ericson2314: we may want to make nix config check usable by NixOS
  • @edolstra: in that case it must not do anything that may fail at build time
  • @roberth: may add a --static flag to ensure this

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-02-24-nix-team-meeting-minutes-35/25757/1

[fricklerhandwerk]

Discussed in the Nix team meeting 2022-02-27:

• @Ericson2314: We shouldn't stabilize the command right now because we need to refactor the internal configuration system, and that might leak in the interface
  • agreement, this is not low-hanging fruit
• idea approved

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-02-27-nix-team-meeting-minutes-36/25890/1