lib.evalModules: Add extendModules and type to result

[roberth]

Motivation for this change

Primary goal: allow configuration systems to be embedded in other configuration systems more easily.

• Allows the simultaneous construction of top-level invocations and
  submodule types. Any configuration system that previously only exposed evalConfig can now also expose a type easily.

• Allow NixOS specialisations to be expressed cleanly

Side catch:

• Improve specialisation option docs

Example integration of modules into a configuration system (à la NixOS / home manager / arion / etc)

let
  baseConfig = lib.types.evalModules {
    modules = myBuiltInModules;
    inherit specialArgs;
  };
in {
  inherit (baseConfig) type;
  evalConfig = configuration: baseConfig.extendModules { modules = [ configuration ]; };
}

This is the successor of #143133.

Closes #141733

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.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.

[roberth]

Tests pass and hashes are unchanged for nixosTests.nginx, nixosTests.specialisation and the manual ((import ./. {}).nixos {}).config.system.build.manual.manualHTML. EDIT: specialisation only until the "rephrase" commit, which changes option order. EDIT 2: Reverted that to expedite this pr.

[roberth]

acme test also works.

I've dug through the issues and PRs and found no surprises.

[roberth]

I'm out of ideas to further validate and test this solution. Please review :)

[roberth]

I'm pretty sure this broke cross-compiled specialisations before.

[roberth]

Considering that the design is already the result of discussion with @infinisil and I've validated the design in three use cases and I've reduced the potential impact to near zero by reverting the specialisations commit, I will go ahead and merge this in order not to stall progress. Limited existence/availability of maintainers for this very specific code was also a factor of consideration. I'll be happy to receive feedback after the merge and I am available (and capable) to resolve any issues if they do happen to arise. I don't merge my own PRs lightly.

[infinisil]

Sounds good!