doc/module-system: Introduce concepts

[hsjobeki]

This is the rebase of #240531.

Since I cannot force push to the hercules-ci mirror branch ^^

I'd like to merge the things that we can agree on; are improvments
The docs might not be complete but we can still iterate on them. Everything else would just bloat this PR

@roberth:
This is reference material in a form that is meant to provide somewhat of an overview.

It doesn't defers to other sections to provide the full depth, which is uncharacteristic of reference material.
It is however not an explanation, as it is does not cover the why; only the what. (Except for the eDSL part I guess)

I made a tracking issue here for the remaining work #391001

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[fricklerhandwerk]

Suggested change

	It was historically known as the NixOS module system.
	It was historically known as the NixOS module system, but the mechanism is not specific to NixOS.

[fricklerhandwerk]

Suggested change

	- **dynamic type checking** to find mistakes early on, improving error messages;
	- **dynamic type checking** to catch and locate mistakes early on;

It would be a bit tone deaf to speak about improving error messages from the position of official documentation.

[fricklerhandwerk]

Suggested change

	The following sections are dense introductory reference material.
	The following sections are introductory reference material.

Not sure what "dense" would mean.

[fricklerhandwerk]

In order to further reduce scope of each PR (and also to avoid an eternal construction site) I recommend to splice out smaller chunks:

• glossary (currently called "concepts", which is probably an okay name)

  This can be fairly standalone, with bonus points for linking a few occurrences to the new definitions

• conceptual introduction (it's an eDSL adding types, etc.)

  This can be fairly easy since we already have some places where we put serious work into boiling down concise descriptions. Again as a bonus, that change can also remove redundant occurrences and link to the new subsection from where it makes sense.

• syntax

  Most of the stuff is already in the "writing modules" section but in tutorial form. This change may as well dismantle the tutorial, and if there are valuable bits that aren't examples those can be used as inspiration to improve the tutorial on nix.dev.

• library

  This should be done programmatically anyway, please let's not start another pile of unstructured characters now that we have docstrings.

This is essentially what the tracking issue also says, but what I want to say is that I see no reason to splat out everything at once and leave each piece incomplete for an indefinite amount of time.